Re: array support patch phase 1 patch
От | Joe Conway |
---|---|
Тема | Re: array support patch phase 1 patch |
Дата | |
Msg-id | 3EDAEDD4.7040102@joeconway.com обсуждение исходный текст |
Ответ на | array support patch phase 1 patch (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: array support patch phase 1 patch
|
Список | pgsql-patches |
Tom Lane wrote: > Joe Conway <mail@joeconway.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
В списке pgsql-patches по дате отправления: