Re: array support patch phase 1 patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: array support patch phase 1 patch
Date: 2003-06-02 13:27:54
Message-ID: 7751.1054560474@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> 1) I found that addTargetToSortList() uses compatible_oper_opid() if it
> is given a specific opname, but ordering_oper_opid (which in turn uses
> ordering_oper()) if not. Do you know in what cases will
> addTargetToSortList() get called with a specific opname?

I think only for "ORDER BY foo ASC/DESC/USING opname". As long as the
"<" and ">" (ASC, DESC) cases work, it should be okay to punt on other
operator names for arrays.

> 2) AlterTableAddForeignKeyConstraint() uses oper() to check directly for
> an "=" operator. This should probably be changed anyway to
> equality_oper(), shouldn't it?

Can't use it as-is, since the datatypes may differ.

> 3) process_implied_equality() uses compatible_oper() to directly obtain
> "=" operator. This should also be changed anyway to equality_oper(),
> shouldn't it?

As above.

I'm not sure though that any of these cases really are of concern. Do
we care in any of them whether failure to find the operator is postponed
till runtime? ANALYZE needs to know because it has a fallback path if
there's no "<" operator, but ORDER BY does not.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-06-02 13:47:25 Re: Start-scripts linux
Previous Message Shridhar Daithankar 2003-06-02 06:55:03 Re: ECPG thread-safety