Re: array support patch phase 1 patch - Mailing list pgsql-patches

From Tom Lane
Subject Re: array support patch phase 1 patch
Date
Msg-id 1227.1054525826@sss.pgh.pa.us
Whole thread Raw
In response to Re: array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
Responses Re: array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
Joe Conway <mail@joeconway.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

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: array support patch phase 1 patch
Next
From: Tom Lane
Date:
Subject: Re: array support patch phase 1 patch