Re: [DOCS] [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
On Tue, Sep 6, 2011 at 10:54 PM, Bruce Momjian wrote: > Josh Kupershmidt wrote: >> How about a doc tweak like the attached? > > Perfect. Applied to 9.0, 9.1, and head. Thanks. Sorry for the delay. Err, as Tom's first comment in this thread explains, Pavel and I were both wrong: the variables in question are indeed NULL, not undefined. I think the docs were fine the way they were. Josh -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
Josh Kupershmidt wrote: > On Tue, Sep 6, 2011 at 10:54 PM, Bruce Momjian wrote: > > Josh Kupershmidt wrote: > >> How about a doc tweak like the attached? > > > > Perfect. ?Applied to 9.0, 9.1, and head. ?Thanks. ?Sorry for the delay. > > Err, as Tom's first comment in this thread explains, Pavel and I were > both wrong: the variables in question are indeed NULL, not undefined. > I think the docs were fine the way they were. OK, reverted. I did not see Tom's comment. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
2011/9/7 Josh Kupershmidt : > On Tue, Sep 6, 2011 at 10:54 PM, Bruce Momjian wrote: >> Josh Kupershmidt wrote: >>> How about a doc tweak like the attached? >> >> Perfect. Applied to 9.0, 9.1, and head. Thanks. Sorry for the delay. > > Err, as Tom's first comment in this thread explains, Pavel and I were > both wrong: the variables in question are indeed NULL, not undefined. > I think the docs were fine the way they were. There is maybe bug - these variables are defined, but they has not assigned tupledesc, so there is not possible do any test postgres=# create table omega (a int, b int); CREATE TABLE postgres=# create or replace function foo_trig() postgres-# returns trigger as $$ postgres$# begin postgres$# raise notice '%', new; postgres$# return null; postgres$# end; postgres$# $$ language plpgsql; CREATE FUNCTION postgres=# create trigger xxx after delete on omega for each row execute procedure foo_trig(); CREATE TRIGGER postgres=# insert into omega values(20); INSERT 0 1 postgres=# delete from omega; ERROR: record "new" is not assigned yet DETAIL: The tuple structure of a not-yet-assigned record is indeterminate. CONTEXT: PL/pgSQL function "foo_trig" line 3 at RAISE so current text in documentation is not correct too. Regards Pavel Stehule > > Josh > -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] createuser/dropuser username
Tom Lane wrote: > Susanne Ebrecht writes: > > PostgreSQL even is so intelligent - that when you say: > > $ createdb "tEst" - it will ignore the quotes - you will get database > > named tEst and not > > named "tEst". > > Not true. The reason you don't get quotes there is that the shell > stripped them off. Try '"tEst"' ... > > The current behavior is something that we settled on years ago, after > thinking about the interaction between shell quoting rules and SQL > quoting rules. If we don't treat SQL names appearing on command lines > as spelled literally, then you have to quote them if you don't want them > downcased --- and doing that in a way that the shell won't mangle is > unpleasant, as in my example above. So we ruled that all utilities that > take a SQL name from the command line should auto-quote the name. > > I'm pretty sure this is documented somewhere, but perhaps not in the > place where Grzegorz looked for it ... Uh, I did some digging after this email report and found it does need some cleanup, which is done in the attached patch. It removes quoting for table references in clusterdb and index/table references in reindexdb, and adds a general documentation overview about when case is preserved and suggests quoting, and adds documentation where special quoting happens. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/ref/createdb.sgml b/doc/src/sgml/ref/createdb.sgml new file mode 100644 index 3e50173..60a54cd *** a/doc/src/sgml/ref/createdb.sgml --- b/doc/src/sgml/ref/createdb.sgml *** PostgreSQL documentation *** 90,96 --tablespace=tablespace ! Specifies the default tablespace for the database. --- 90,96 --tablespace=tablespace ! Specifies the default tablespace for the database (double-quoted internally). *** PostgreSQL documentation *** 153,159 --owner=owner ! Specifies the database user who will own the new database. --- 153,160 --owner=owner ! Specifies the database user who will own the new database ! (double-quoted internally). *** PostgreSQL documentation *** 163,169 --template=template ! Specifies the template database from which to build this database. --- 164,171 --template=template ! Specifies the template database from which to build this ! database (double-quoted internally). diff --git a/doc/src/sgml/ref/createlang.sgml b/doc/src/sgml/ref/createlang.sgml new file mode 100644 index f01f298..7f9459a *** a/doc/src/sgml/ref/createlang.sgml --- b/doc/src/sgml/ref/createlang.sgml *** PostgreSQL documentation *** 70,76 langname ! Specifies the name of the procedural language to be installed. --- 70,77 langname ! Specifies the name of the procedural language to be ! installed. (automatically lower-cased) diff --git a/doc/src/sgml/ref/droplang.sgml b/doc/src/sgml/ref/droplang.sgml new file mode 100644 index 04c3a60..fa7e913 *** a/doc/src/sgml/ref/droplang.sgml --- b/doc/src/sgml/ref/droplang.sgml *** PostgreSQL documentation *** 73,78 --- 73,79 Specifies the name of the procedural language to be removed. + (automatically lower-cased) diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml new file mode 100644 index 9ae8000..5fd6410 *** a/doc/src/sgml/reference.sgml --- b/doc/src/sgml/reference.sgml *** *** 198,203 --- 198,211 applications is that they can be run on any host, independent of where the database server resides. + + + When specified on the command line, user and databases names have + their case preserved — the presence of spaces or special + characters might require quoting. Table names and other identifiers + do not have their case preserved, except where documented, and + might require quoting. + &clusterdb; diff --git a/src/bin/scripts/clusterdb.c b/src/bin/scripts/clusterdb.c new file mode 100644 index f4c317a..3742091 *** a/src/bin/scripts/clusterdb.c --- b/src/bin/scripts/clusterdb.c *** cluster_one_database(const char *dbname, *** 177,183 if (verbose) appendPQExpBuffer(&sql, " VERBOSE"); if (table) ! appendPQExpBuffer(&sql, " %s", fmtId(table)); appendPQExpBuffer(&sql, ";\n"); conn = connectDatabase(db
Re: [DOCS] createuser/dropuser username
Bruce Momjian writes: > Uh, I did some digging after this email report and found it does need > some cleanup, which is done in the attached patch. > It removes quoting for table references in clusterdb and index/table > references in reindexdb, Uh, surely that breaks things. Or did you miss my statement that the current behavior is what is intended? > and adds a general documentation overview about > when case is preserved and suggests quoting, and adds documentation > where special quoting happens. I don't find the documentation changes to be improvements either. Possibly instead of > ! Specifies the default tablespace for the database (double-quoted > internally). you could do something like Specifies the default tablespace for the database. (This name is not subject to case-folding.) > + > + When specified on the command line, user and databases names have > + their case preserved — the presence of spaces or special > + characters might require quoting. Table names and other identifiers > + do not have their case preserved, except where documented, and > + might require quoting. > + This latter sentence is just plain wrong. regards, tom lane -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] createuser/dropuser username
Tom Lane wrote: > Bruce Momjian writes: > > Uh, I did some digging after this email report and found it does need > > some cleanup, which is done in the attached patch. > > > It removes quoting for table references in clusterdb and index/table > > references in reindexdb, > > Uh, surely that breaks things. Or did you miss my statement that the > current behavior is what is intended? I saw that, but how is that consistent with other command-line tools? What is the logic that has some tools preserve case and others not? > > and adds a general documentation overview about > > when case is preserved and suggests quoting, and adds documentation > > where special quoting happens. > > I don't find the documentation changes to be improvements either. > Possibly instead of > > > ! Specifies the default tablespace for the database (double-quoted > > internally). > > you could do something like > > Specifies the default tablespace for the database. (This name > is not subject to case-folding.) OK. > > + > > + When specified on the command line, user and databases names have > > + their case preserved — the presence of spaces or special > > + characters might require quoting. Table names and other identifiers > > + do not have their case preserved, except where documented, and > > + might require quoting. > > + > > This latter sentence is just plain wrong. Really? Pg_dump doesn't preserve case for table names: pg_dump -t Test test $ pg_dump -t Test test pg_dump: No matching tables were found $ pg_dump -t '"Test"' test -- -- PostgreSQL database dump ... and vacuumdb certainly does not: vacuumdb --analyze --verbose --table 'foo(bar)' xyzzy $ vacuumdb --analyze --verbose --table 'Test (x)' test vacuumdb: vacuuming of table "Test (x)" in database "test" failed: ERROR: relation "test" does not exist $ vacuumdb --analyze --verbose --table '"Test" (x)' test INFO: vacuuming "public.Test" INFO: "Test": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages ... Who does? reindexdb and clusterdb did before my patch, but that hardly seems consistent. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
