Robert Haas robertmh...@gmail.com writes:
Having said all this, I don't really object to the alternate proposal
of creating a set of words that are reserved as relation names but not
as column names, either, especially if it would allow us to make some
other existing keywords less-reserved.
On Fri, Dec 25, 2009 at 4:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Having said all this, I don't really object to the alternate proposal
of creating a set of words that are reserved as relation names but not
as column names, either, especially if it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Dec 25, 2009 at 05:27:44PM -0500, Robert Haas wrote:
On Fri, Dec 25, 2009 at 4:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
[...]
I think what we should learn from this case, as well as the recent
Robert Haas robertmh...@gmail.com writes:
It compiles without warnings for me. There's only one production that
allows exactly one word between INDEX and ON.
In that case you broke something. I'm too tired to work out exactly
what.
regards, tom lane
--
Sent via
On Thu, Dec 24, 2009 at 12:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It compiles without warnings for me. There's only one production that
allows exactly one word between INDEX and ON.
In that case you broke something. I'm too tired to work out
On Wed, Dec 23, 2009 at 3:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
David E. Wheeler wrote:
+1 if it prevents indexes from being named CONCURRENTLY.
Yeah, if you really want to have an index named like that you can use
double quotes. Seems a
Greg Stark gsst...@mit.edu writes:
On Wed, Dec 23, 2009 at 3:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, this will also break tables and columns named concurrently.
I think the odds of it being a problem are small, but still it is
a reserved word that shouldn't be reserved according to the
I wrote:
Greg Stark gsst...@mit.edu writes:
On Wed, Dec 23, 2009 at 3:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, this will also break tables and columns named concurrently.
I think the odds of it being a problem are small, but still it is
a reserved word that shouldn't be reserved
On Wed, Dec 23, 2009 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, not really. Past the grammar there is no way to tell concurrently
from concurrently, ie, if we did it like that then you couldn't even
use double quotes to get around it. Don't overthink this: either we
reserve the word
Greg Stark gsst...@mit.edu writes:
? Well still in the realm of overthinking Is there anything to be
gained by having a class of reserved word which can be used for
columns but not relations?
If there were more than a single member of the class, I might think
it was worth the trouble ...
On Wed, Dec 23, 2009 at 6:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
? Well still in the realm of overthinking Is there anything to be
gained by having a class of reserved word which can be used for
columns but not relations?
If there were more than a single member of the class, I might
Greg Stark gsst...@mit.edu writes:
On Wed, Dec 23, 2009 at 6:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there were more than a single member of the class, I might think
it was worth the trouble ...
A quick glace at the list shows relatively few that actually need to
be barred from columns.
On Wed, Dec 23, 2009 at 7:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still not really eager to introduce yet another category of
keywords, but perhaps it is worth doing. Comments?
If we consider that they can now be a problem in pl/pgsql, it might be
a good idea to consider it for this
On Wed, Dec 23, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
On Wed, Dec 23, 2009 at 6:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there were more than a single member of the class, I might think
it was worth the trouble ...
A quick glace at the
Robert Haas robertmh...@gmail.com writes:
I'm about to get on a plane, but just to make you hurl here's another
half-assed approach.
Uh ... I don't see what that fixes? If CONCURRENTLY can be a column
name this is still ambiguous.
regards, tom lane
--
Sent via
On Dec 23, 2009, at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm about to get on a plane, but just to make you hurl here's another
half-assed approach.
Uh ... I don't see what that fixes? If CONCURRENTLY can be a column
name this is still
Robert Haas robertmh...@gmail.com writes:
On Dec 23, 2009, at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh ... I don't see what that fixes? If CONCURRENTLY can be a column
name this is still ambiguous.
How?
Because CONCURRENTLY can still be reduced as tricky_index_name, so
it still
On Dec 23, 2009, at 1:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Dec 23, 2009, at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh ... I don't see what that fixes? If CONCURRENTLY can be a column
name this is still ambiguous.
How?
Because
Peter Eisentraut pete...@gmx.net writes:
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx.
Having done all the groundwork to support that nicely, I find that it
doesn't work because of
I wrote:
The trouble with changing the index attnames for expressions is that it
increases the risk of collisions with attnames for regular index
columns. You can hit that case today:
regression=# create table foo (f1 int, f2 text);
CREATE TABLE
regression=# create index fooi on foo(f1,
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx.
Having done all the groundwork to support that nicely, I find that it
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
... AFAICT, the only way
we could support this syntax would be to make ON a reserved word.
Or at least more reserved than it is now. We used up all the wiggle
room we had by making CONCURRENTLY non-reserved.
And here's Simon
I wrote:
Hmm. It would actually work if we made CONCURRENTLY reserved instead;
and that would fix Simon's gripe too. That's kind of weird from a
standards-compliance POV, but in terms of the risk of breaking
applications it might be better than reserving ON.
Wait a minute. I must have been
On Dec 22, 2009, at 7:31 PM, Tom Lane wrote:
Wait a minute. I must have been looking at the wrong keyword list
--- ON already is reserved. The problem is exactly that it can't
tell whether CREATE INDEX CONCURRENTLY ON ... means to default the
index name or to create an index named
David E. Wheeler wrote:
On Dec 22, 2009, at 7:31 PM, Tom Lane wrote:
Wait a minute. I must have been looking at the wrong keyword list
--- ON already is reserved. The problem is exactly that it can't
tell whether CREATE INDEX CONCURRENTLY ON ... means to default the
index name or to
Alvaro Herrera alvhe...@commandprompt.com writes:
David E. Wheeler wrote:
+1 if it prevents indexes from being named CONCURRENTLY.
Yeah, if you really want to have an index named like that you can use
double quotes. Seems a sensible compromise.
Well, this will also break tables and columns
Peter Eisentraut wrote:
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx.
Why wouldn't it default to a name more like:
CREATE INDEX foo(a) on foo(a);
which would extend pretty
I wrote:
Although, having said that, I realize we just opened that can of worms
with the exclusion-constraint patch:
regression=# create table foo (f1 text, exclude (lower(f1) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index foo_exclusion
for table foo
CREATE TABLE
On Dec 20, 2009, at 13:58 , Tom Lane wrote:
* Append _index not _key if it's not a constraint-related index.
_idx instead of _index keeps things a bit shorter (and a couple of
keystrokes further from NAMEDATALEN). There's precedent for
abbreviations with automatic naming in Postgres,
Michael Glaesemann g...@seespotcode.net writes:
On Dec 20, 2009, at 13:58 , Tom Lane wrote:
* Append _index not _key if it's not a constraint-related index.
_idx instead of _index keeps things a bit shorter (and a couple of
keystrokes further from NAMEDATALEN). There's precedent for
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx. We already do this in a number
of places such as constraint names and sequences without much trouble.
In most cases you don't really need
2009/12/20 Peter Eisentraut pete...@gmx.net:
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
Yes, please.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut pete...@gmx.net writes:
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx. We already do this in a number
of places such as constraint names and sequences without much
In response to Peter Eisentraut :
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx. We already do this in a number
of places such as constraint names and sequences without much
I wrote:
In the cases where that's sensible, you can use constraint syntax, no?
I really doubt that it's that easy to pick a sensible name for an index
on an expression, for example.
Although, having said that, I realize we just opened that can of worms
with the exclusion-constraint patch:
35 matches
Mail list logo
