daniele.varra...@gmail.com writes:
CREATE TABLE foo
(
id serial primary key,
f1 integer NOT NULL
);
CREATE INDEX foo_idx1 ON foo (f1);
CREATE INDEX foo_idx2 ON foo (f1) WHERE id 10;
COMMENT ON INDEX foo_idx2 IS 'whatever';
create table foo2 (like foo including all);
I've applied
The following bug has been logged on the website:
Bug reference: 6734
Logged by: Daniele Varrazzo
Email address: daniele.varra...@gmail.com
PostgreSQL version: 9.1.4
Operating system: Linux
Description:
Weird, isn't it? Test case below.
Dropping the comment, the
On Fri, Jul 13, 2012 at 12:00:14PM +, daniele.varra...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 6734
Logged by: Daniele Varrazzo
Email address: daniele.varra...@gmail.com
PostgreSQL version: 9.1.4
Operating system: Linux
On Fri, Jul 13, 2012 at 2:24 PM, Ryan Kelly rpkell...@gmail.com wrote:
On Fri, Jul 13, 2012 at 12:00:14PM +, daniele.varra...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 6734
Logged by: Daniele Varrazzo
Email address:
Ryan Kelly rpkell...@gmail.com writes:
The comments on chooseIndexName in src/backend/parser/parse_utilcmd.c say:
* XXX this is inherently broken because the indexes aren't created
* immediately, so we fail to resolve conflicts when the same name is
* derived for multiple indexes.
Which
Daniele Varrazzo daniele.varra...@gmail.com writes:
Wouldn't it be better to call the indexes NEWTABLE_OLDINDEXNAME?
Then the CREATE LIKE command would fail altogether if that name were
already taken. Postponing the selection of the index name to the time
when DefineIndex runs is really the
On Fri, Jul 13, 2012 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniele Varrazzo daniele.varra...@gmail.com writes:
Wouldn't it be better to call the indexes NEWTABLE_OLDINDEXNAME?
Then the CREATE LIKE command would fail altogether if that name were
already taken. Postponing the
