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
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 -r
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
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'Connel
"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 gramma
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 i
"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
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'
"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 SQ
> 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.
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 t
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
---
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
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 yo
14 matches
Mail list logo
