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
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 |