From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: array support patch phase 1 patch |
Date: | 2003-06-02 06:25:24 |
Message-ID: | 3EDAEDD4.7040102@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>What if we modify equality_oper() and friends to do the check for us
>>when argtype is a varlena array?
>
>>If an array type is checked for an ordering operator, its element type
>>now *must* have an ordering operator in order for the result to be
>>meaningful. Same goes for ordering_oper().
>
> That sounds more like a solution. Is there anyplace else we need to
> push knowledge of this into? (Offhand I can't think of any, but ...)
>
Poking around:
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? If it's only
for "non-standard" operators, then we should be fine here I'd think.
2) AlterTableAddForeignKeyConstraint() uses oper() to check directly for
an "=" operator. This should probably be changed anyway to
equality_oper(), shouldn't it?
3) process_implied_equality() uses compatible_oper() to directly obtain
"=" operator. This should also be changed anyway to equality_oper(),
shouldn't it?
4) SelectSortFunction() might need work -- I'll have to study that one
more.
That's all I could find that looked suspect.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-06-02 06:55:03 | Re: ECPG thread-safety |
Previous Message | Tom Lane | 2003-06-02 04:52:02 | Re: array support patch phase 1 patch |