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
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
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
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
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
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
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
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
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-
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
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
On 1/2/18 11:47, Tom Lane wrote:
> +1 --- seems like a new bool column is the thing. Or may we should merge
> "proisprocedure" with proisagg and proiswindow into an enum prokind?
> Although that would break some existing client-side code.
prokind sounds good. I'll look into that.
--
Peter Eise
On 01/02/2018 02:14 PM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 1:57 PM, Andrew Dunstan
> wrote:
>> Yeah, but these things don't feel like they belong in the same category.
>> The fact that we have to ask this question is a symptom of that.
> Well, that's got to be asked about any representa
On Tue, Jan 2, 2018 at 1:57 PM, Andrew Dunstan
wrote:
> Yeah, but these things don't feel like they belong in the same category.
> The fact that we have to ask this question is a symptom of that.
Well, that's got to be asked about any representation we choose - that
question is the motivation for
On 01/02/2018 01:45 PM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 11:47 AM, Tom Lane wrote:
>>> Anyway, I think it would be better to invent an explicit way to
>>> represent whether something is a procedure rather than relying on
>>> overloading prorettype to tell us.
>> +1 --- seems like a ne
On Tue, Jan 2, 2018 at 11:47 AM, Tom Lane wrote:
>> Anyway, I think it would be better to invent an explicit way to
>> represent whether something is a procedure rather than relying on
>> overloading prorettype to tell us.
>
> +1 --- seems like a new bool column is the thing. Or may we should mer
2018-01-02 17:47 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > I agree that we need this, but using prorettype = InvalidOid to do it
> > might not be the best way, because it only works for procedures that
> > don't return anything. If a procedure could return, say, an integer,
>
> Good point,
Robert Haas writes:
> I agree that we need this, but using prorettype = InvalidOid to do it
> might not be the best way, because it only works for procedures that
> don't return anything. If a procedure could return, say, an integer,
Good point, because that is possible in some other systems, an
On Wed, Nov 8, 2017 at 9:21 AM, Peter Eisentraut
wrote:
>> Why not use VOIDOID for the prorettype value?
>
> We need a way to distinguish functions that are callable by SELECT and
> procedures that are callable by CALL.
I agree that we need this, but using prorettype = InvalidOid to do it
might n
On 2 December 2017 at 01:31, Peter Eisentraut
wrote:
> On 11/30/17 15:50, Thomas Munro wrote:
>> postgres=# \df
>>List of functions
>> Schema | Name | Result data type | Argument data types | Type
>> +--+--+-+--
>> publi
On Fri, Dec 1, 2017 at 9:31 AM, Peter Eisentraut
wrote:
> On 11/30/17 15:50, Thomas Munro wrote:
>> postgres=# \df
>>List of functions
>> Schema | Name | Result data type | Argument data types | Type
>> +--+--+-+--
>> pu
On 11/30/17 15:50, Thomas Munro wrote:
> postgres=# \df
>List of functions
> Schema | Name | Result data type | Argument data types | Type
> +--+--+-+--
> public | bar | integer | i integer | func
> p
On Fri, Dec 1, 2017 at 7:48 AM, Peter Eisentraut
wrote:
> On 11/29/17 14:17, Andrew Dunstan wrote:
>> On 11/28/2017 10:03 AM, Peter Eisentraut wrote:
>>> Here is a new patch that addresses the previous review comments.
>>>
>>> If there are no new comments, I think this might be ready to go.
>>
>>
On 11/29/17 14:17, Andrew Dunstan wrote:
> On 11/28/2017 10:03 AM, Peter Eisentraut wrote:
>> Here is a new patch that addresses the previous review comments.
>>
>> If there are no new comments, I think this might be ready to go.
>
> Looks good to me. Marking ready for committer.
committed
--
On 11/28/2017 10:03 AM, Peter Eisentraut wrote:
> Here is a new patch that addresses the previous review comments.
>
> If there are no new comments, I think this might be ready to go.
>
Looks good to me. Marking ready for committer.
cheers
andrew
--
Andrew Dunstanhttps://www
On 11/28/17 10:34, Simon Riggs wrote:
> Is ERRCODE_INVALID_FUNCTION_DEFINITION still appropriate?
Well, maybe not, but changing that is likely more trouble than it's worth.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & S
On 29 November 2017 at 02:03, Peter Eisentraut
wrote:
> Here is a new patch that addresses the previous review comments.
>
> If there are no new comments, I think this might be ready to go.
Is ERRCODE_INVALID_FUNCTION_DEFINITION still appropriate?
Other than that, looks ready to go.
--
Simon R
On 11/23/17 00:59, Craig Ringer wrote:
> Exactly. If we want to handle OUT params this way they really need to be
> the first resultset for just this reason. That could possibly be done by
> the glue code reserving a spot in the resultset list and filling it in
> at the end of the p
On 23 November 2017 at 03:47, Andrew Dunstan wrote:
>
>
> On 11/22/2017 02:39 PM, Corey Huinker wrote:
> >
> >
> > T-SQL procedures returns data or OUT variables.
> >
> > I remember, it was very frustrating
> >
> > Maybe first result can be reserved for OUT variables, others for
> >
On 11/22/2017 02:39 PM, Corey Huinker wrote:
>
>
> T-SQL procedures returns data or OUT variables.
>
> I remember, it was very frustrating
>
> Maybe first result can be reserved for OUT variables, others for
> multi result set
>
>
> It's been many years, but if I recall correctly,
>
>
> T-SQL procedures returns data or OUT variables.
>
> I remember, it was very frustrating
>
> Maybe first result can be reserved for OUT variables, others for multi
> result set
>
>
It's been many years, but if I recall correctly, T-SQL returns a series of
result sets, with no description of th
On 11/22/2017 01:10 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 11/20/17 16:25, Andrew Dunstan wrote:
>>> We should document where returned values in PL procedures are ignored
>>> (plperl, pltcl) and where they are not (plpython, plpgsql). Maybe we
>>> should think about possibly being
2017-11-22 19:01 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 11/20/17 16:25, Andrew Dunstan wrote:
> > I've been through this fairly closely, and I think it's pretty much
> > committable. The only big item that stands out for me is the issue of
> > OUT parameters.
>
> I fi
Peter Eisentraut writes:
> On 11/20/17 16:25, Andrew Dunstan wrote:
>> We should document where returned values in PL procedures are ignored
>> (plperl, pltcl) and where they are not (plpython, plpgsql). Maybe we
>> should think about possibly being more consistent here, too.
> Yeah, suggestions?
On 11/20/17 16:25, Andrew Dunstan wrote:
> I've been through this fairly closely, and I think it's pretty much
> committable. The only big item that stands out for me is the issue of
> OUT parameters.
I figured that that's something that would come up. I had intentionally
prohibited OUT parameter
On 11/20/2017 04:25 PM, I wrote:
> I've been through this fairly closely, and I think it's pretty much
> committable. The only big item that stands out for me is the issue of
> OUT parameters.
>
> While returning multiple result sets will be a useful feature, it's also
> very common in my experie
On 11/14/2017 10:54 AM, Peter Eisentraut wrote:
> Here is an updated patch. It's updated for the recent documentation
> format changes. I added some more documentation as suggested by reviewers.
>
> I also added more tests about how the various privilege commands (GRANT,
> GRANT on ALL, default
Simon Riggs wrote:
> It would seem to be implied by the SQLStandard that Functions and
> Procedures occupy the same namespace, since they are both Routines.
>
> I can't see any benefit from having foo() function AND foo() procedure
> at same time. It would certainly confuse most people that come f
Peter Eisentraut writes:
> On 11/14/17 11:14, Tom Lane wrote:
>> ... Do we really want the existence of
>> a function foo(int) to mean that you can't create a SQL procedure named
>> foo and taking one int argument?
> Yes, that is defined that way by the SQL standard.
Meh. OK, then it has to be
On 11/14/17 11:14, Tom Lane wrote:
>> The common functionality between functions and procedures is like 98%
>> [citation needed], so they definitely belong there, even more so than
>> aggregates, for example.
> No, I don't think so. The core reason why not is that in
>
> SELECT foo(...) FRO
On 14 November 2017 at 12:56, Daniel Verite wrote:
> Tom Lane wrote:
>
>> Do we really want the existence of a function foo(int) to mean
>> that you can't create a SQL procedure named
>> foo and taking one int argument?
>
> Isn't it pretty much implied by the
> ALTER | DROP ROUTINE foo(...
Tom Lane wrote:
> Do we really want the existence of a function foo(int) to mean
> that you can't create a SQL procedure named
> foo and taking one int argument?
Isn't it pretty much implied by the
ALTER | DROP ROUTINE foo(...)
commands where foo(...) may be either a procedure
or a functi
2017-11-14 17:14 GMT+01:00 Tom Lane :
> Peter Eisentraut writes:
> > On 11/8/17 09:54, Tom Lane wrote:
> >> Do procedures of this ilk belong in pg_proc at all? It seems like a
> large
> >> fraction of the attributes tracked in pg_proc are senseless for this
> >> purpose. A new catalog might be
Peter Eisentraut writes:
> On 11/8/17 09:54, Tom Lane wrote:
>> Do procedures of this ilk belong in pg_proc at all? It seems like a large
>> fraction of the attributes tracked in pg_proc are senseless for this
>> purpose. A new catalog might be a better approach.
> The common functionality betw
On 11/8/17 09:54, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 10/31/17 14:23, Tom Lane wrote:
>>> Why not use VOIDOID for the prorettype value?
>
>> We need a way to distinguish functions that are callable by SELECT and
>> procedures that are callable by CALL.
>
> Do procedures of this ilk
On 11/8/17 12:15, Merlin Moncure wrote:
> On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut
> wrote:
>> On 11/8/17 11:11, Merlin Moncure wrote:
>>> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut
>>> wrote:
I have already submitted a separate patch that addresses these questions.
>>>
>>> Ma
46 matches
Mail list logo
