Re: prokind column (was Re: [HACKERS] SQL procedures) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: prokind column (was Re: [HACKERS] SQL procedures)
Date
Msg-id 15889.1519499311@sss.pgh.pa.us
Whole thread Raw
In response to prokind column (was Re: [HACKERS] SQL procedures)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: prokind column (was Re: [HACKERS] SQL procedures)
Re: prokind column (was Re: [HACKERS] SQL procedures)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Here is this patch updated.  The client changes are now complete and all
> the tests pass.  I have also rolled back the places where the code used
> prorettype to detect procedures and replaced this by the new facility.

I took a quick look through this and noted a few small problems; the
only one worth mentioning here is that you've broken psql tab completion
for functions and aggregates when talking to a pre-v11 server.
I don't think that's acceptable; however, since tab-complete.c has no
existing provisions for adjusting its queries based on server version,
it's not really clear what to do to fix it.  I'm sure that's soluble
(and I think I recall a recent thread bumping up against the same
problem for another change), but it needs a bit more sweat.

We need a plan for when/how to apply this, along with the proposed
bootstrap data conversion patch, which obviously conflicts with it
significantly.  Looking through the stuff pending in next month's
commitfest, we are fortunate in that only a few of those patches
seem to need to touch pg_proc.h at all, and none have really large
deltas AFAICS (I might've missed something though).  I propose
proceeding as follows:

1. Get this patch in as soon as we can resolve its remaining weak
spots.  That will force rebasing of pending patches that touch
pg_proc.h, but I don't think it'll be painful, since the needed
changes are pretty small and obvious.

2. During the March commitfest, adjust the bootstrap data conversion
patch to handle this change, and review it generally.

3. At the end of the 'fest, or whenever we've dealt with all other
patches that need to touch the bootstrap source data, apply the
data conversion patch.

My thought here is that the data conversion patch is going to break
basically every pending patch that touches src/include/catalog/,
so we ought to apply it at a point where that list of patches is short
and there's lots of time for people to redo them.  Hence, end of the
dev cycle is the right time.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: Online enabling of checksums
Next
From: Greg Stark
Date:
Subject: Query pattern tha Postgres doesn't handle well