Hi,
attached is patch with Czech .po files updates (some files are new).
Tested with actual CVS:
patch -p1nls-cs-08292004.patch
patching file src/bin/initdb/nls.mk
patching file src/bin/initdb/po/cs.po
patching file src/bin/pg_controldata/po/cs.po
patching file
Bruce Momjian schrieb:
Should I apply this change?
#define TIMEZONE_GLOBAL ((int)_timezone)
yes, please.
I have no time yet, to come up with the better patch. It's already monday.
---
Reini Urban wrote:
Bruce Momjian
Gavin Sherry wrote:
The attached patch contributes:
- database_size(name)
- relation_size(text)
I sent in a dbsize patch to make these functions tablespace aware...
AFAIR your patch was applied, but it misses tables in non-default
tablespaces.
Regards,
Andreas
---(end of
On Mon, 30 Aug 2004, Andreas Pflug wrote:
Gavin Sherry wrote:
The attached patch contributes:
- database_size(name)
- relation_size(text)
I sent in a dbsize patch to make these functions tablespace aware...
AFAIR your patch was applied, but it misses tables in non-default
Ed L. [EMAIL PROTECTED] writes:
On Saturday August 28 2004 9:30, Bruce Momjian wrote:
Are we going to change this before beta2? I have not seen a final
patch yet.
Attached is a revised patch:
Applied with minor revisions.
I did not add UTC offset logic nor logic to shift to top of the
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 60/1440 minutes, but would like to add
that
Ed L. [EMAIL PROTECTED] writes:
One idea for handling the round-to-localtime issue from the other end of the
problem: optionally rotate logs upon an *interpolated* filename change.
The code-as-committed wants to be able to predict the time change in
advance. I'm not totally wedded to that,