Re: [HACKERS] SQL procedures

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(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:14:04
Message-ID: CA+TgmoZDwHMAogmZwW4S+smDoYqq=wLRuw7sxdQr-BuJ5+VbgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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).

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-01-02 19:17:34 Re: TODO list (was Re: Contributing with code)
Previous Message Andrew Dunstan 2018-01-02 18:57:25 Re: [HACKERS] SQL procedures