[DOCS] EXTRACT Clarification
Switching this thread to DOCS and renaming it... Anyway, I think that this situation calls for some clarification in the docs. If others agree, I'd be happy to submit a potential patch. I'm thinking something like this (with thanks to Stephan): Note: EXTRACT is not a true function. SQL defines it as an expression that happens to look similar to a function call. Is this wording acceptable? I'd imagine putting it at the end of 9.8.1. Also, are there other expressions that fall into this category? I don't know the spec well enough to know. -tfo On Sep 29, 2004, at 1:30 AM, Stephan Szabo wrote: [EMAIL PROTECTED] On Tue, 28 Sep 2004, Thomas F.O'Connell wrote: From 11.5 in the docs: "The syntax of the CREATE INDEX command normally requires writing parentheses around index expressions, as shown in the second example. The parentheses may be omitted when the expression is just a function call, as in the first example." But when I try this: db=# CREATE INDEX expression_idx on some_table( extract( year from some_column ) ); Extract(year from some_column) is not really just a function call it's an expression that looks similar to a function call because that's how SQL defined it. ---(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
[DOCS] Add tablespace index entry
This adds an index entry for tablespaces which is tricky to find otherwise. Kris Jurka Index: doc/src/sgml/manage-ag.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/manage-ag.sgml,v retrieving revision 2.33 diff -c -r2.33 manage-ag.sgml *** doc/src/sgml/manage-ag.sgml 7 Aug 2004 19:14:45 - 2.33 --- doc/src/sgml/manage-ag.sgml 29 Sep 2004 13:20:11 - *** *** 335,340 --- 335,344 Tablespaces + +tablespace + + Tablespaces in PostgreSQL allow database administrators to define locations in the file system where the files representing ---(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: [DOCS] EXTRACT Clarification
On Wed, 29 Sep 2004, Thomas F.O'Connell wrote: > Note: EXTRACT is not a true function. SQL defines it as an expression > that happens to look similar to a function call. > > Also, are there other expressions that fall into this category? I don't > know the spec well enough to know. At least COALESCE and NULLIF are not functions. Kris Jurka ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [DOCS] EXTRACT Clarification
It seems like it would be worth noting these (and any others) in the docs in some way. Is there a way for someone without a copy of the spec to be aware of which are functions and which are not, otherwise? -tfo On Sep 29, 2004, at 9:25 AM, Kris Jurka wrote: On Wed, 29 Sep 2004, Thomas F.O'Connell wrote: Note: EXTRACT is not a true function. SQL defines it as an expression that happens to look similar to a function call. Also, are there other expressions that fall into this category? I don't know the spec well enough to know. At least COALESCE and NULLIF are not functions. Kris Jurka ---(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: [DOCS] EXTRACT Clarification
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes: > I'm thinking something like this (with thanks to Stephan): > Note: EXTRACT is not a true function. SQL defines it as an expression > that happens to look similar to a function call. Rather than documenting this, maybe we should change the grammar to allow it? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [DOCS] EXTRACT Clarification
That seems reasonable, too, although I was interested to learn that this (and a few other expressions) weren't actually functions. Whether that's actually meaningful for any implementation purposes is debatable. Even if the grammar is changed to allow it, it's probably worth making a note of it in SQL compatibility documentation. Speaking of which, since functions aren't in the SQL Commands reference, where the compatibility documentation resides, does anyone see value in adding compatibility information to The SQL Language section as a whole? I can contribute what I know, but I don't have a full copy of the spec. -tfo On Sep 29, 2004, at 11:32 AM, Tom Lane wrote: "Thomas F.O'Connell" <[EMAIL PROTECTED]> writes: I'm thinking something like this (with thanks to Stephan): Note: EXTRACT is not a true function. SQL defines it as an expression that happens to look similar to a function call. Rather than documenting this, maybe we should change the grammar to allow it? regards, tom lane ---(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: [DOCS] EXTRACT Clarification
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes: > That seems reasonable, too, although I was interested to learn that > this (and a few other expressions) weren't actually functions. They are functions ... but not from the point of view of the grammar, which has special productions for them to cope with SQL's whimsical syntax requirements. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [DOCS] EXTRACT Clarification
Ah, so it's really a question of whether the syntactic sugar of CREATE INDEX is considered worthwhile by the developers (rather than a standards compliance issue) because CREATE INDEX is not a part of the SQL spec? Now that I understand what's going on, I don't have a strong preference, but I'd say that either it needs noting in the documentation or it should be added to the grammar. And if it isn't going to hit the grammar for 7.4.x, I'd be happy to supply a doc patch. -tfo On Sep 29, 2004, at 12:09 PM, Tom Lane wrote: "Thomas F. O'Connell" <[EMAIL PROTECTED]> writes: That seems reasonable, too, although I was interested to learn that this (and a few other expressions) weren't actually functions. They are functions ... but not from the point of view of the grammar, which has special productions for them to cope with SQL's whimsical syntax requirements. regards, tom lane ---(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: [DOCS] EXTRACT Clarification
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes: > Ah, so it's really a question of whether the syntactic sugar of CREATE > INDEX is considered worthwhile by the developers (rather than a > standards compliance issue) because CREATE INDEX is not a part of the > SQL spec? Right. It is not a SQL-compliance item because CREATE INDEX isn't in the standard in the first place. The fact that the CREATE INDEX syntax allows for some things that look like function calls but not for other things that look like function calls is an annoyance, no doubt about it. I'm not sure how important it is to fix though. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [DOCS] EXTRACT Clarification
> The fact that the CREATE INDEX syntax allows for some things that look > like function calls but not for other things that look like function > calls is an annoyance, no doubt about it. I'm not sure how important > it is to fix though. Turns out to be easy to fix in the grammar, so I did it. regards, tom lane ---(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: [DOCS] EXTRACT Clarification
Nice. Thanks. My guess is that because this problem has existed until now there's no point in adding any notes to the 7.4.x docs? -tfo On Sep 29, 2004, at 7:46 PM, Tom Lane wrote: The fact that the CREATE INDEX syntax allows for some things that look like function calls but not for other things that look like function calls is an annoyance, no doubt about it. I'm not sure how important it is to fix though. Turns out to be easy to fix in the grammar, so I did it. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [DOCS] Add tablespace index entry
On Wed, 2004-09-29 at 23:21, Kris Jurka wrote: > This adds an index entry for tablespaces which is tricky to find > otherwise. Patch applied -- thanks! (FWIW, adding index entries for stuff is a pretty easy TODO item, if anyone's looking for something worth contributing...) -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [DOCS] Add tablespace index entry
On Thu, Sep 30, 2004 at 12:40:01PM +1000, Neil Conway wrote: > On Wed, 2004-09-29 at 23:21, Kris Jurka wrote: > > This adds an index entry for tablespaces which is tricky to find > > otherwise. > > Patch applied -- thanks! > > (FWIW, adding index entries for stuff is a pretty easy TODO item, if > anyone's looking for something worth contributing...) Cool! Please apply this one as well ;-) -- Alvaro Herrera () "La experiencia nos dice que el hombre peló millones de veces las patatas, pero era forzoso admitir la posibilidad de que en un caso entre millones, las patatas pelarían al hombre" (Ijon Tichy) Index: doc/src/sgml/ref/deallocate.sgml === RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/deallocate.sgml,v retrieving revision 1.6 diff -c -r1.6 deallocate.sgml *** doc/src/sgml/ref/deallocate.sgml20 Sep 2004 00:04:19 - 1.6 --- doc/src/sgml/ref/deallocate.sgml24 Sep 2004 03:04:48 - *** *** 18,23 --- 18,28 DEALLOCATE + + prepared statements + DEALLOCATE + + DEALLOCATE [ PREPARE ] plan_name Index: doc/src/sgml/ref/execute.sgml === RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/execute.sgml,v retrieving revision 1.11 diff -c -r1.11 execute.sgml *** doc/src/sgml/ref/execute.sgml 20 Sep 2004 00:04:19 - 1.11 --- doc/src/sgml/ref/execute.sgml 24 Sep 2004 03:04:43 - *** *** 18,23 --- 18,28 EXECUTE + + prepared statements + EXECUTE + + EXECUTE plan_name [ (parameter [, ...] ) ] Index: doc/src/sgml/ref/explain.sgml === RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/explain.sgml,v retrieving revision 1.33 diff -c -r1.33 explain.sgml *** doc/src/sgml/ref/explain.sgml 9 Mar 2004 16:57:47 - 1.33 --- doc/src/sgml/ref/explain.sgml 24 Sep 2004 03:05:08 - *** *** 18,23 --- 18,33 EXPLAIN + + prepared statements + EXPLAIN + + + + cursors + EXPLAIN + + EXPLAIN [ ANALYZE ] [ VERBOSE ] statement Index: doc/src/sgml/ref/prepare.sgml === RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/prepare.sgml,v retrieving revision 1.13 diff -c -r1.13 prepare.sgml *** doc/src/sgml/ref/prepare.sgml 20 Sep 2004 00:04:19 - 1.13 --- doc/src/sgml/ref/prepare.sgml 24 Sep 2004 03:04:38 - *** *** 18,23 --- 18,28 PREPARE + + prepared statements + PREPARE + + PREPARE plan_name [ (datatype [, ...] ) ] AS statement ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [DOCS] Add tablespace index entry
On Thu, 2004-09-30 at 13:58, Alvaro Herrera wrote: > Cool! Please apply this one as well ;-) Patch applied, with some editorializing. Thanks! -Neil ---(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
