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