Re: [BUGS] "strange" rule behavior with nextval on new.* fields
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, "Rules are macros, which is why referring to NEW.id causes another evaluation of nextval(). If you don't want that to happen then use a trigger." > Anyway, it really looks like a strange behavior to me, so misleading and > unexpected that it could be qualified as a bug rather than a feature. I > did not spot such caveats by a quick look thru the documentation. 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. Thoughts from the developers? I'd offer to write the additional documentation but my understanding of the rule system is pretty shallow. Nevertheless, maybe I could at least write something that others could build on. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] "strange" rule behavior with nextval on new.* fields
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 the docs so that triggers are presented as being simpler than rules (come first, etc). I think right now the docs actively mislead newbies into choosing rules in cases where triggers would be much better. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Broken CIDR: no fix in 7.4.6?
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 wonder if I can safely use diff -r1.53 -r1.54 .../network.c to patch 7.4.6 sources... -- Fduch M. Pravking ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Broken CIDR: no fix in 7.4.6?
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.4.6 still has 1.47.2.1 with no fix. > > I wonder if I can safely use diff -r1.53 -r1.54 .../network.c to patch > 7.4.6 sources... Yes, you can, but you should be sure all your existing data is clean or you will have problems with revalidating some of your data. We didn't backpatch this fix because it was something that might break existing bad data that got into your system. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1313: problems with array syntax parsing in SQL
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 generate the
following entry '{"A","B "} : the space(s) between the latest double quote
and the closing brace is/are added to the latest item of the array.
Fixed in cvs:
regression=# select version();
version
PostgreSQL 8.0.0beta4 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
(1 row)
regression=# create table test(f1 text[]);
CREATE TABLE
regression=# insert into test values ('{"A", "B" }');
INSERT 155428 1
regression=# select * from test;
f1
---
{A,B}
(1 row)
regression=# insert into test values ('{ }');
INSERT 155429 1
regression=# select * from test;
f1
---
{A,B}
{}
(2 rows)
Joe
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] Broken CIDR: no fix in 7.4.6?
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 > > > > 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 wonder if I can safely use diff -r1.53 -r1.54 .../network.c to patch > > 7.4.6 sources... > > Yes, you can, but you should be sure all your existing data is clean or > you will have problems with revalidating some of your data. We didn't > backpatch this fix because it was something that might break existing > bad data that got into your system. Good point. Of course, I'll check, thanks. -- Fduch M. Pravking ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1316: Alter Name of a Serial Field won't change the corresponding SEQUENCE name
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 Details: Alter Name of a Serial Field won't change the corresponding SEQUENCE name say we had a table: atable (field1 Serial) it implies to create a sequence: atable_field1_seq 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 This will cause problem when we restore a backup: NOTICE: create table atable implies create a sequence atable_field2_seq ... (here it defaults to tablename_fieldname_seq again) ... SET SEQUENCE atable_field1_seq ... (here it still tries to restore the actually sequence we used) since it's not created, it will fail. And the value of atable_field2_seq is NOT set !) this will ruin the whole field. The same thing may happen if you change the name of a table that has serial field(s). Regards, Hongyi ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] "strange" rule behavior with nextval on new.* fields
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 as being simpler than rules (come first, etc). I think right now the docs actively mislead newbies into choosing rules in cases where triggers would be much better. ISTM that having SQL as a language for trivial triggers would also help. RULEs are SQL, although triggers must be C or PL*. That could also be a candidate TODO, next to "improve the doc"? Thanks for your answer, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1316: Alter Name of a Serial Field won't change the corresponding SEQUENCE name
"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 restore a backup: pg_dump in 8.0 has a workaround for this. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] BUG #1317: plPHP does not recgnize booleans
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 boolean... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1317: plPHP does not recgnize booleans
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)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] pg_dump case folding bug
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 but solved it and generated a patch
then e-mail it to [EMAIL PROTECTED] instead. Please use the
command "diff -c" to generate the patch.
You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Russell Smith
Your email address : As From address
System Configuration
-
Architecture (example: Intel Pentium) : AMD 2000XP
Operating System (example: Linux 2.4.18) : Gentoo Linux 2.4.20-r9
PostgreSQL version (example: PostgreSQL-8.0): PostgreSQL-8.0-beta4
Compiler used (example: gcc 2.95.2) : gcc (GCC) 3.3.3 20040412 (Gentoo
Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)
Please enter a FULL description of your problem:
pg_dump -i -h '10.0.0.5' -p '5432' -s 'test' -t '"Test"'
pg_dump does not fold case, and quote table and schema names correctly.
the above line will dump the table named "Test"
pg_dump -i -h '10.0.0.5' -p '5432' -s 'test' -t 'Test'
the above will dump the table named Test
I believe the correct output from 1 should be to dump the table named Test.
and correct output from 2 should dump the table named test
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
Reproduction from commands in description.
If you know how this problem might be fixed, list the solution below:
-
Attempted patches attached. Most code taken from libpq and modified for
pg_dump.
Index: pg_dump.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.392
diff -c -r1.392 pg_dump.c
*** pg_dump.c 6 Nov 2004 19:36:02 - 1.392
--- pg_dump.c 13 Nov 2004 03:29:17 -
***
*** 112,117
--- 112,118
static int disable_dollar_quoting = 0;
+ static char* caseCastedQuotedName(const char *ident);
static void help(const char *progname);
static NamespaceInfo *findNamespace(Oid nsoid, Oid objoid);
static void dumpTableData(Archive *fout, TableDataInfo *tdinfo);
***
*** 326,332
break;
case 'n': /* Dump data for this schema only */
! selectSchemaName = strdup(optarg);
break;
case 'o': /* Dump oids */
--- 327,333
break;
case 'n': /* Dump data for this schema only */
! selectSchemaName = caseCastedQuotedName(optarg);
break;
case 'o': /* Dump oids */
***
*** 355,361
break;
case 't': /* Dump data for this table only */
! selectTableName = strdup(optarg);
break;
case 'u':
--- 356,362
break;
case 't': /* Dump data for this table only */
! selectTableName = caseCastedQuotedName(optarg);
break;
case 'u':
***
*** 655,660
--- 656,731
exit(0);
}
+ /*
+ * caseCastedQuotedName: fold the case of a column unless "'d
+ *
+ * The column name is parsed as if it were in a SQL statement, including
+ * case-folding and double-quote processing. But note a possible gotcha:
+ * downcasing in the frontend might follow different locale rules than
+ * downcasing in the backend...
+ *
+ * Returns NULL on failure.
+ */
+ static char*
+ caseCastedQuotedName(const char *ident)
+ {
+ char *ident_case;
+ bool in_quotes;
+ char *iptr;
+ char *optr;
+
+ /*
+ * Note: it is correct to reject a zero-length input string; the
+ * proper input to match a zero-length field name would be "".
+ */
+ if (ident == NULL ||
+ ident[0] == '\0')
+ return NULL;
+
+ /*
+ * Note: this code will not reject partially quoted strings, eg
+ * foo"BAR"foo will become fooBARfoo when it probably ought to be an
+ * error condition.
+ */
+ ident_case = strdup(ident);
+ if (ident_case == NULL)
+ return NULL; /* grotty */
+
+ in_quotes = false;
+ optr = ident_case;
+ for (iptr = ident_case; *iptr; iptr++)
+ {
+ char c = *iptr;
+
+ if (in_quotes)
+ {
+ if (c == '"')
+ {
+ if (iptr[1] == '"')
+ {
+ /* doubled quotes become a single quote */
+ *optr++ = '"';
+ iptr++;
+ }
+ else
+ in_quotes = false;
+ }
+ else
+ *optr++ = c;
+ }
+ else if (c == '"')
+ in_quotes = true;
+ else
+ {
+
Re: [BUGS] pg_dump case folding bug
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 shell command line are taken literally, without dequoting or case folding. Yes, this is inconsistent with the behavior if the same string were entered within an SQL context, but then again the command line isn't an SQL context. The main reason for this position is that the shell imposes its own quoting rules that we can't avoid, and these rules are not very compatible with the SQL identifier quoting rules. Do you *really* want to have to type '"Test"' when you could just write Test ? Even more to the point, the only argument in favor of adding code to do it like this is to try to make the shell command line context just like the SQL context, but *you can't make it so*. If you could make "Test" on the command line work just like "Test" in SQL it'd be great ... but you can't because the shell will strip the double quotes before you ever see them. We went around a few times on this, but eventually decided it was unhelpful to try to emulate the SQL quoting behavior. BTW, this behavior is consistent across all our command-line tools; if we did want to change it it'd affect much more than just pg_dump. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
