Russell Smith <[EMAIL PROTECTED]> writes:
> pg_dump does not fold case, and quote table and schema names correctly.
This is not a bug; it is a behavior we deliberately adopted years ago,
after unsuccessful experiments with behavior like what you propose.
The rule is that names appearing on a shel
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem
PostgreSQL Bugs List wrote:
> plPHP can't understand postgresql boolean...
We do not maintain or distribute plPHP. Please report problems to where
you got it from.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
The following bug has been logged online:
Bug reference: 1317
Logged by: Tom Katt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: RH 7 Linux
Description:plPHP does not recgnize booleans
Details:
plPHP can't understand postgresql boo
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> if I alter table atable alter field1 rename to field2
> it becomes atable(field2 Serial)
> however, the sequence stays: atable_field1_seq
> it's not tablename_fieldname_seq any more
It's intended to do that.
> This will cause problem when we re
Dear Tom,
This comes up often enough that maybe it warrants a "Caveats with
Rules" section in "The Rule System" chapter and a link to that section
in the CREATE RULE documentation, as well as mention in the FAQ.
Yeah. I have also thought about reorganizing the docs so that triggers
are presented
The following bug has been logged online:
Bug reference: 1316
Logged by: Hongyi Gao
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: SuSe Linux 9
Description:Alter Name of a Serial Field won't change the
corresponding SEQUENCE name
D
On Fri, Nov 12, 2004 at 11:37:24AM -0500, Bruce Momjian wrote:
> Alexander M. Pravking wrote:
> >
> > As been said, in 7.4.5 CIDR data type has been accepted values with
> > non-zero bits to the right of >24-bit mask:
> >
> > http://archives.postgresql.org/pgsql-bugs/2004-10/msg00081.php
> >
> >
PostgreSQL Bugs List wrote:
In INSERT statements the string '{}' is correctly parsed as an empty array
when '{ }' is not, as if the space was signifiant, and generates a syntax
error.
Also
'{"A", "B"}' will be correctly parsed when
'{"A", "B" }' (note the space before the closing brace ) will
Alexander M. Pravking wrote:
>
> As been said, in 7.4.5 CIDR data type has been accepted values with
> non-zero bits to the right of >24-bit mask:
>
> http://archives.postgresql.org/pgsql-bugs/2004-10/msg00081.php
>
> In CVS head src/backend/utils/adt/network.c (1.54) has a fix by Bruce,
> but 7
As been said, in 7.4.5 CIDR data type has been accepted values with
non-zero bits to the right of >24-bit mask:
http://archives.postgresql.org/pgsql-bugs/2004-10/msg00081.php
In CVS head src/backend/utils/adt/network.c (1.54) has a fix by Bruce,
but 7.4.6 still has 1.47.2.1 with no fix.
I wonde
Michael Fuhr <[EMAIL PROTECTED]> writes:
> This comes up often enough that maybe it warrants a "Caveats with
> Rules" section in "The Rule System" chapter and a link to that
> section in the CREATE RULE documentation, as well as mention in the
> FAQ.
Yeah. I have also thought about reorganizing t
On Wed, Nov 10, 2004 at 10:23:41AM +0100, Fabien COELHO wrote:
> It seems that "on update do also" rules the new.* fields are evaluated
> several times instead of being computed once, which is a bad idea, esp.
> for "nextval".
This comes up often and the response is usually something like,
"Rul
13 matches
Mail list logo
