Re: [HACKERS] SQL procedures
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] SQL procedures |
Дата | |
Msg-id | d35eb271-cd6d-c7ff-6139-830a8b1e680a@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] SQL procedures (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: