From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: array support patch phase 1 patch |
Date: | 2003-06-04 17:29:28 |
Message-ID: | 3EDE2C78.4060803@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> BTW, it might be better for array_cmp to insist that the array element
> type have a default btree opclass, and use the comparison proc from that
> opclass in place of equality_oper() and ordering_oper(). This'd be
> faster (only one call per comparison) as well as more semantically pure.
Sounds like a good idea. Should I work this now, or wait for more comments?
> I've got some other problems with this patch (I still don't understand
> what the hacking on aggregates is supposed to accomplish, for example)
The aggregates hacking was a bit convoluted by the desire to support
polymorphic aggregates using polymorphic functions. You end up with many
possible states, some of which are invalid because they don't provide
enough context to resolve the polymorphic types. Any suggestions?
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-06-04 21:47:06 | Re: pgstattuple for schemas |
Previous Message | Tom Lane | 2003-06-04 17:04:27 | Re: array support patch phase 1 patch |