Re: [HACKERS] REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Date
Msg-id CAB7nPqSS7xVKGkQbroiJ_wFgxa9n3COnemGzeXv36-A3XLbAeg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Thu, Dec 21, 2017 at 11:46 AM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
> Michael Paquier wrote:
>> Well, the idea is really to get rid of that as there are already
>> facilities of this kind for CREATE TABLE LIKE in the parser and ALTER
>> TABLE when rewriting a relation. It is not really attractive to have a
>> 3rd method in the backend code to do the same kind of things, for a
>> method that is even harder to maintain than the other two.
>
> I dislike the backend code that uses SPI and manufacturing node to
> re-creates indexes.  IMO we should get rid of it.  Let's not call it
> "facilities", but rather "grotty hacks".

Aha. You are making my day here ;)

> I think before suggesting to add even more code to perpetuate that idea,
> we should think about going in the other direction.  I have not tried to
> write the code, but it should be possible to have an intermediate
> function called by ProcessUtility* which transforms the IndexStmt into
> an internal representation, then calls DefineIndex.   This way, all this
> code that wants to create indexes for backend-internal reasons can
> create the internal representation directly then call DefineIndex,
> instead of the horrible hacks they use today creating parse nodes by
> hand.

Yeah, that would be likely possible. I am not volunteering for that in
the short term though..
-- 
Michael


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] replace GrantObjectType with ObjectType
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0