Re: array support patch phase 1 patch - Mailing list pgsql-patches

From Tom Lane
Subject Re: array support patch phase 1 patch
Date
Msg-id 7751.1054560474@sss.pgh.pa.us
Whole thread Raw
In response to Re: array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
Joe Conway <mail@joeconway.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

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: array support patch phase 1 patch
Next
From: Joe Conway
Date:
Subject: Re: array support patch phase 1 patch