Tom,
> As best I can tell, this is coming out because pgtz.c thinks that
> /usr/share/timezone is where Postgres' own timezone files are; which
> implies that get_share_directory() is returning /usr/share; which does
> not make a lot of sense. I think you must have used nondefault
> configuration
>> Please. Also, what nondefault configuration or postgresql.conf settings
>> are you using?
> Sorry for delay. Attached.
> And --with-perl --with-odbc
As best I can tell, this is coming out because pgtz.c thinks that
/usr/share/timezone is where Postgres' own timezone files are; which
implies
On Wed, 3 Nov 2004, PostgreSQL Bugs List wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1305
> Logged by: Károly Segesdi
>
> Email address: [EMAIL PROTECTED]
>
> PostgreSQL version: 7.4.5
>
> Operating system: slackware 10.0
>
> Description:ca
The following bug has been logged online:
Bug reference: 1305
Logged by: Károly Segesdi
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: slackware 10.0
Description:can't use the type 'number' with alter table
Details:
somedb=# alter
Brendan,
> Description: Â Â Â Âupdate does not honor order of subselect
>
> Details:
>
> SQL Update command does not follow the order of a WHERE field IN subselect.
>
> In the following code, I try to reset the order of rows in a column by
> updating an order field. ÂUpdate does not honor the orde
> over, i think, network problems or ODBC errors there are some wrong packets
> which crash postgresql backend.
> TCP package with postgresql data (hex) 58 00 00 00 00 00
> doest it.
Not for me. The backend logs a complaint about invalid message length
and disconnects, which is what it's suppos
PostgreSQL Bugs List wrote:
> SQL Update command does not follow the order of a WHERE field IN
> subselect.
What could possibly have given you the idea that it should?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
