Re: [HACKERS] SQL procedures - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] SQL procedures
Date
Msg-id d35eb271-cd6d-c7ff-6139-830a8b1e680a@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

On 01/02/2018 02:14 PM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 1:57 PM, Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com> 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 not liking the use of prorettype for
> this purpose, so it's only fair to ask whether any alternative has the
> same problem.


I think there's broad agreement about not liking use of prorettype for
this purpose.


>
>> A
>> boolean feels more natural to me here, although I acknowledge it will
>> result in a tiny amount of catalog bloat. Tom's point about client-side
>> code is also valid. I don't feel very strongly about it, though.
> I think the catalog bloat is too minor to care about, but if these
> things really are mutually exclusive, it's more natural to have them
> use a single flag character rather than a series of Booleans.
> Otherwise, it may be unclear to the casual observer (or hacker) that
> at most one of the Booleans can be true, possibly leading to user
> confusion (or bugs).



Fair point. I don't recall if we discussed anything like this when
window functions were introduced.


>
> It's pretty well impossible to introduce new features without
> occasionally changing the catalog representation.  We had several
> people grumble when I replaced relistemp with relpersistence, and we
> (rightly, IMHO) told those people to suck it up and deal.  I don't
> think we should react any differently here.  I recognize that it's a
> pain, but it's not that much of a pain, and it may even be helpful to
> tool authors who actually need to handle procedures differently than
> functions, which is probably a lot of them.  pgAdmin for example seems
> like it will certainly need to care.



I agree.


cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: TODO list (was Re: Contributing with code)
Next
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL