| От | Robert Haas |
|---|---|
| Тема | Re: operator exclusion constraints |
| Дата | |
| Msg-id | 603c8f070911172013m6e930f7bnd7dba5764d60b31d@mail.gmail.com обсуждение |
| Ответ на | Re: operator exclusion constraints (Jeff Davis <pgsql@j-davis.com>) |
| Ответы |
Re: operator exclusion constraints
Re: operator exclusion constraints Re: operator exclusion constraints |
| Список | pgsql-hackers |
On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis <pgsql@j-davis.com> wrote: > New patches attached. Forgive me if this is discussed before, but why does this store the strategy numbers of the relevant operators instead of the operators themselves? It seems like this could lead to surprising behavior if the user modifies the definition of the operator class. I'm wondering if we can't use the existing BuildIndexValueDescription() rather than the new function tuple_as_string(). I realize there are two tuples, but maybe it makes sense to just call it twice? I'm attaching a revised doc patch for your consideration. ...Robert
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера