Re: [HACKERS] SQL procedures

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] SQL procedures
Date: 2018-01-02 19:35:19
Message-ID: d35eb271-cd6d-c7ff-6139-830a8b1e680a@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/02/2018 02:14 PM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 1:57 PM, Andrew Dunstan
> <andrew(dot)dunstan(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2018-01-02 19:44:24 Re: [HACKERS] SQL/JSON in PostgreSQL
Previous Message Robert Haas 2018-01-02 19:24:49 Re: TODO list (was Re: Contributing with code)