Re: ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard
Date: 2015-07-22 02:56:10
Message-ID: CAB7nPqT8BM7Fep2jJM_6Z5Xug-psv77+adYVWjHSW4NB3EEYpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 22, 2015 at 9:34 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Notice that the collation specifier is gone. Oops.
>
> As it is not possible to specify directly a constraint for a PRIMARY
> KEY expression, what about switching dumpConstraint to have it use
> first a CREATE INDEX query with the collation and then use ALTER TABLE
> to attach the constraint to it? I am noticing that we already fetch
> the index definition in indxinfo via pg_get_indexdef. Thoughts?

And poking at that I have finished with the attached that adds a
CREATE INDEX query before ALTER TABLE ADD CONSTRAINT, to which a USING
INDEX is appended. Storage options as well as building the column list
becomes unnecessary because indexdef already provides everything what
is needed, so this patch makes dump rely more on what is on
backend-side.
--
Michael

Attachment Content-Type Size
20150722_pgdump_index_collate_fix.patch application/x-patch 1.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2015-07-22 03:40:58 Re: Alpha2/Beta1
Previous Message Michael Paquier 2015-07-22 01:31:03 Re: "make check" changes have caused buildfarm deterioration.