On 21 December 2017 at 11:31, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Thu, Dec 21, 2017 at 11:46 AM, Alvaro Herrera > <alvhe...@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.. > It sounds like that'd make some of ALTER TABLE a bit less ... upsetting ... too. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
