Re: array support patch phase 1 patch

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

In response to

Responses

Browse pgsql-patches by date

  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