Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-03-02 Thread Peter Eisentraut
On 2/28/18 17:37, Peter Eisentraut wrote: > On 2/28/18 15:45, Tom Lane wrote: >> I have reviewed this patch and attach an updated version below. >> I've rebased it up to today, fixed a few minor errors, and adopted >> most of Michael's suggestions. Also, since I remain desperately >> unhappy with

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-28 Thread Michael Paquier
On Wed, Feb 28, 2018 at 05:37:11PM -0500, Peter Eisentraut wrote: > On 2/28/18 15:45, Tom Lane wrote: >> I have reviewed this patch and attach an updated version below. >> I've rebased it up to today, fixed a few minor errors, and adopted >> most of Michael's suggestions. Also, since I remain desp

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-28 Thread Peter Eisentraut
On 2/28/18 15:45, Tom Lane wrote: > I have reviewed this patch and attach an updated version below. > I've rebased it up to today, fixed a few minor errors, and adopted > most of Michael's suggestions. Also, since I remain desperately > unhappy with putting zeroes into prorettype, I changed it to

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-27 Thread Michael Paquier
On Tue, Feb 27, 2018 at 11:50:31AM -0500, Tom Lane wrote: > We support the various psql/describe.c features against old servers, > so it would be quite inconsistent for tab completion not to work > similarly. There are some gaps in that already, as per the other > thread, but we should clean those

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-27 Thread Tom Lane
Catalin Iacob writes: > On Tue, Feb 27, 2018 at 4:03 AM, Michael Paquier wrote: >> I would just recommend users to use a version of psql matching >> the one of the server instead of putting an extra load of maintenance >> into psql for years to come > Breaking tab completion in new psql against

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-27 Thread Catalin Iacob
On Tue, Feb 27, 2018 at 4:03 AM, Michael Paquier wrote: > I would just recommend users to use a version of psql matching > the one of the server instead of putting an extra load of maintenance > into psql for years to come Breaking tab completion in new psql against old servers might be acceptabl

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-26 Thread Michael Paquier
On Mon, Feb 26, 2018 at 02:03:19PM -0500, Tom Lane wrote: > I'm not sure that other patch will get in; AFAICS it's incomplete and > rather controversial. But I guess we could put this issue on the > open-items list so we don't forget. +1. We already know that we want to do a switch to prokind an

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-26 Thread Tom Lane
Peter Eisentraut writes: > On 2/24/18 14:08, Tom Lane wrote: >> 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

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-26 Thread Peter Eisentraut
On 2/24/18 14:08, Tom Lane wrote: > 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-

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-25 Thread John Naylor
On 2/25/18, Tom Lane wrote: > We need a plan for when/how to apply this, along with the proposed > bootstrap data conversion patch, which obviously conflicts with it > significantly. The bulk changes in the bootstrap data patch are scripted rather than patched, so the prokind patch will pose litt

Re: prokind column (was Re: [HACKERS] SQL procedures)

2018-02-24 Thread Tom Lane
Peter Eisentraut 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 s