[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] Coercing compound types to use generic ROW comparison operators
From:       "Merlin Moncure" <mmoncure () gmail ! com>
Date:       2007-10-12 12:54:44
Message-ID: b42b73150710120554g6064d1cdw2c43697a8e7d9be6 () mail ! gmail ! com
[Download RAW message or body]

On 10/11/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Randall Lucas <rlucas@tercent.com> writes:
> > Still, this would fail in a nested situation because it wouldn't
> > recurse (if col1 of the compound type were another compound type,
> > ferinstance), as would your suggestion above.  It might be worthwhile
> > to allow choosing to use the default ROW comparison operator at
> > composite type creation (which would provide a more elegant solution to
> > nested situations).
>
> You are incorrectly supposing that there *is* such an animal as a
> default row comparison operator --- actually, ROW() = ROW() is expanded
> at parse time into field-by-field comparisons.  This is usually a good
> thing since it gives the planner more flexibility.

AIUI, the biggest problem with the current behavior is that there is
no way to usefully index composite types, it looks like

create index bar_idx on bar(f);
create index bar_idx on bar((f).*);
create index bar_idx on bar((f).a, (f).b);

are all invalid. the only way to do it that i can see is to create a
separate function for each field of the composite you want to index.

merlin

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
[prev in list] [next in list] [prev in thread] [next in thread]