From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: array support patch phase 1 patch |
Date: | 2003-06-02 03:50:26 |
Message-ID: | 1227.1054525826@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> on ANALYZE (and therefore on initdb) I get this:
> template1=# analyze;
> ERROR: Unable to identify an ordering operator for type aclitem
> Use an explicit ordering operator or modify the query
> This is where I ran into the problem with an equality operator earlier.
> Problem this time is that an ordering operator makes no sense for
> aclitems -- does it? Any thoughts on how to work around this?
Seems like you'll have to invent one. ANALYZE can hardly be expected
not to try to develop histogram stats for an array-of-aclitem column
when the array-of-aclitem datatype appears to be offering a '<'
operator.
I'm a bit troubled by the implications though. If anyone creates a
datatype foo, they'd better not try to make an array-of-foo column
unless they've made '=' and '<' operators for foo. This seems a bit
evil, especially for types like "point" which don't have obvious '<'
semantics, but *do* have uses for arrays. Maybe we'd better think
twice about how to handle this. How could the lack of an underlying
'<' be reflected back to the array-type level?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-06-02 03:51:49 | Re: array support patch phase 1 patch |
Previous Message | Joe Conway | 2003-06-02 03:40:06 | Re: array support patch phase 1 patch |