From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Arrays of domains |
Date: | 2017-07-11 17:45:51 |
Message-ID: | 20170711174551.GD28048@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 11, 2017 at 12:44:33PM -0400, Tom Lane wrote:
> Over in
> https://www.postgresql.org/message-id/877ezgyn60.fsf@metapensiero.it
> there's a gripe about array_agg() not working for a domain type.
> It fails because we don't create an array type over a domain type,
> so the parser can't identify a suitable output type for the polymorphic
> aggregate.
>
> We could imagine tweaking the polymorphic-function resolution rules
> so that a domain matched to ANYELEMENT is smashed to its base type,
> allowing ANYARRAY to be resolved as the base type's array type.
> While that would be a pretty localized fix, it seems like a kluge
> to me.
>
> Probably a better answer is to start supporting arrays over domain
> types. That was left unimplemented in the original domains patch,
> but AFAICS not for any better reason than lack of round tuits.
> I did find an argument here:
> https://www.postgresql.org/message-id/3C98F7F6.29FE1248@redhat.com
> that the SQL spec forbids domains over arrays, but that's the opposite
> case (and a restriction we long since ignored, anyway).
>
> Can anyone think of a reason not to pursue that?
+1 for pursuing it. When operations just compose, users get a more
fun experience.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-07-11 17:58:01 | Re: Arrays of domains |
Previous Message | Alvaro Herrera | 2017-07-11 17:38:07 | Re: pgsql 10: hash indexes testing |