Re: MULTISET and additional functions for ARRAY

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

In response to

Responses

Browse pgsql-hackers by date

  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