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'v
On Fri, Jul 13, 2012 at 4:11 PM, Tom Lane wrote:
> Daniele Varrazzo 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
Daniele Varrazzo 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 only safe thing.
Ryan Kelly 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 looks like the cas
On Fri, Jul 13, 2012 at 2:24 PM, Ryan Kelly 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: daniele.varra...@gmail
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: Lin
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 cre
