Bruce Momjian <[EMAIL PROTECTED]> writes:
> It is strange you are having this problem with finfo only in pg_dump
> because it is used a lot in the backend.
Yeah, but the other places are local variable names and so don't
conflict with a global function name.
regards, tom l
Chris Browne <[EMAIL PROTECTED]> writes:
> CUT0 may be _equivalent_ to GMT, but PostgreSQL isn't aware of it as
> such, so inserts into the table epp_whois_cachemgr were failing with
> much the same error message shown below:
It will probably be more practical to fix this after Magnus' timezone
pa
Your timezone testing will have to wait for the unix timezone code to be
added in a few days.
It is strange you are having this problem with finfo only in pg_dump
because it is used a lot in the backend. Looking at the warning, it
looks like it doesn't like that 'static' specification. If you r
I was wanting to check out what was up with timezone handling with the
latest changes that were committed, as there had been some "biting" on
AIX.
To wit, notice the default time zone on one of our AIX boxes:
bash-2.05a$ date
Tue May 18 21:47:37 GDT 2004
bash-2.05a$ echo $TZ
CUT0GDT
bash-2.05a$
