From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: array support patch phase 1 patch |
Date: | 2003-06-02 04:00:53 |
Message-ID: | 3EDACBF5.4000908@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> 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?
See my last reply. This issue seemed isolated to analyze.
Now there is no requirement to have either '=' or '<' operators for foo
in order to make a foo[] datatype. You'll only need them if you want
statistics. And even at that, if you just create the '=', you'll still
get the reduced level of support as for any other data type that has no
ordering operator. This is how aclitem is currently working with this patch.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-06-02 04:04:55 | Re: array support patch phase 1 patch |
Previous Message | Bruce Momjian | 2003-06-02 03:56:07 | Re: pg_autovacuum update |