Am Dienstag, 14. September 2004 08:24 schrieb Serguei Mokhov:
Sorry for pushing more translation updates on your head
right away ;-) Please apply to 8.0. As of this email
these all should be 100%...
Done.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Am Mittwoch, 15. September 2004 00:24 schrieb Alvaro Herrera:
Attached are updated spanish translations for libpq and pg_dump.
Installed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: don't forget
Am Mittwoch, 15. September 2004 00:49 schrieb Alvaro Herrera:
Attached are pg_controldata and pg_resetxlog spanish translation
updated.
Installed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 8:
Am Mittwoch, 15. September 2004 03:47 schrieb Alvaro Herrera:
Attached are the backend's and pgscripts spanish translation updates.
Installed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 3: if
On Sun, Sep 19, 2004 at 10:29:32AM +0200, LELARGE Guillaume wrote:
Sorry to reply to your post so late...
Peter Eisentraut wrote:
- Please actually encode the files in the declared encoding. The pg_ctl
translation was partially encoded in UTF-8. I did not install that
one.
Stupid of
Tom Lane wrote:
It is now fixed in the attached patch.
Applied with some additional cleanup (the code wasn't multibyte-aware,
and so could get fooled in some Far Eastern encodings).
I am very pleased to hear. This was my first patch submitted. :-)
Best Regards,
Michael Paesold
Alvaro Herrera wrote:
On Sun, Sep 19, 2004 at 10:29:32AM +0200, LELARGE Guillaume wrote:
Sorry to reply to your post so late...
Peter Eisentraut wrote:
- Please actually encode the files in the declared encoding. The pg_ctl
translation was partially encoded in UTF-8. I did not install that
one.
T E Schmitz [EMAIL PROTECTED] writes:
There's a German saying Go and find a parking-meter, i.e. suggesting to pop a
coin in the parking-meter and talk to it as nobody else wants to listen. ;-)
Yes well I anticipated such a response. So I tried my hand at it myself.
Well I finally found a
On Monday August 30 2004 11:07, Ed L. wrote:
On Monday August 30 2004 10:56, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
Attached is a revised patch:
Applied with minor revisions.
I did not add UTC offset logic nor logic to shift to top of the
hour/day for rotation periods of
On Monday September 20 2004 4:43, Ed L. wrote:
This patch rotates logs on local time boundaries instead of UTC
boundaries, e.g., midnight local for daily rotation instead of midnight
UTC. It does so by parsing the %z result from strftime().
... I am arguing for
inclusion of this patch
Ed L. [EMAIL PROTECTED] writes:
Consider the case if one is
truncating logs on rotation and rotating hourly. UTC vs local is
irrelevant. If local time shifts backward from 02:00 to 01:00, our UTC
offset will move in the negative direction. If 1) our policy were to
truncate on rotation,
Greg Stark [EMAIL PROTECTED] writes:
This patch allows subqueries without aliases. This is SQL-non-spec-compliant
syntax that Oracle supports and many users expect to work.
AFAIR you're the first to propose that we ignore the SQL spec here.
When I wrote see if anyone complains, I had in mind
On Monday September 20 2004 4:57, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
Consider the case if one is
truncating logs on rotation and rotating hourly. UTC vs local is
irrelevant. If local time shifts backward from 02:00 to 01:00, our UTC
offset will move in the negative
Ed L. [EMAIL PROTECTED] writes:
+ /*
+ * We expect a strftime(%z) result of the form [+-]HHMM according to
+ * RFC822-conformant dates, where HH:MM is the unsigned UTC offset.
+ * If we don't get it, just return zero offset, and let the logs
+ * rotate on UTC time
Ed L. [EMAIL PROTECTED] writes:
That might work for you, but it's not portable.
Do you consider pg_tm.tm_gmtoff reliable and portable from
pg_localtime(now)?
Yeah, in fact I was just adapting the patch to use that.
regards, tom lane
---(end
On Monday September 20 2004 6:02, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
That might work for you, but it's not portable.
Do you consider pg_tm.tm_gmtoff reliable and portable from
pg_localtime(now)?
Yeah, in fact I was just adapting the patch to use that.
I have a 5-line
Ed L. [EMAIL PROTECTED] writes:
I have a 5-line check-last-filename patch, but it's so small you probably
just want to add it yourself?
Yeah, it's pretty trivial. I just applied the attached.
regards, tom lane
Index: syslogger.c
17 matches
Mail list logo