| 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: | Whole Thread | Raw Message | 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 |