Re: [HACKERS] Domains and arrays and composites, oh my
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Domains and arrays and composites, oh my |
Дата | |
Msg-id | 13131.1506625418@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Domains and arrays and composites, oh my (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Domains and arrays and composites, oh my
|
Список | pgsql-hackers |
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > On 09/28/2017 01:02 PM, Tom Lane wrote: >>> I do think that treating a function returning a domain-over-composite >>> differently from one returning a base composite is a POLA. We'd be very >>> hard put to explain the reasons for it to an end user. >> Do you have any thoughts about how we ought to resolve that? > Not offhand. Maybe we need to revisit the decision not to modify the > executor at all. I think it's more of a parse analysis change: the issue is whether to smash a function's result type to base when determining whether it emits columns. Maybe we could just do that in that context, and otherwise leave domains alone. > One thought I had was that we could invent a new return > type of TYPEFUNC_DOMAIN_COMPOSITE so there would be less danger of a PL > just treating it as an unconstrained base type as it might do if it saw > TYPEFUNC_COMPOSITE. Hmm. That would be a way of forcing the issue, no doubt ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: