From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MULTISET and additional functions for ARRAY |
Date: | 2010-11-12 14:44:35 |
Message-ID: | 9379.1289573075@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Nov 12, 2010 at 12:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The problem is not with the type system: as long as you give multisets
>> different type OIDs from arrays, everything will work fine.
> And thus you must create a THIRD copy of every entry in pg_type. That
> doesn't qualify as a problem?
[ shrug... ] It's less of a problem than the possible alternatives.
IMO anyway. OIDs are cheap ... replacing OIDs with some sort of
ill-specified composite key throughout the system is not.
But I'm still not convinced that this feature is useful enough to
justify the implementation effort. AFAICS there's nothing here that
you couldn't get with some non-default operators on regular arrays,
with orders of magnitude less work and less impact on the rest of the
system. The only reason to consider implementing it as a separate type
category is the SQL committee decided to invent some syntax --- and
given their lousy taste in syntax, I get less enthused every year about
duplicating it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-11-12 14:54:18 | Re: We need index-only scans |
Previous Message | Andrew Dunstan | 2010-11-12 14:39:35 | Re: We need index-only scans |