Re: Expanded Objects and Order By

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Expanded Objects and Order By
Дата
Msg-id 19609.1453134960@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Expanded Objects and Order By  (Paul Ramsey <pramsey@cleverelephant.ca>)
Ответы Re: Expanded Objects and Order By  (Paul Ramsey <pramsey@cleverelephant.ca>)
Список pgsql-hackers
Paul Ramsey <pramsey@cleverelephant.ca> writes:
> So, I've added support for converting postgis in-memory objects into
> expanded outputs, and have overwritten the usual
> lwgeom_to_gserialized() function with one that creates an expanded
> object. I haven't done anything to actually handle expanded objects on
> input, but as I understand it, that's fine, everything is supposed to
> work as normal when handed expanded objects. And thus far, that has
> been true, almost all regression tests work fine.

Hmm ... you do need to be able to flatten them again.  In the given
example, the parser is going to want to form a Const node whose Datum
value is a geometry object, and that Const node needs to be copiable
by copyObject(), which means datumCopy() has to work, and if you look
at that it will exercise EOH_get_flat_size/EOH_flatten_into when the
input routine originally produced an expanded object.

The error message is very strange; it's hard to see how toying with the
internal representation of Consts could cause that.  I think the
hypothesis of a memory clobber is stronger than you give it credit for,
especially since you see the behavior changing for seemingly unrelated
reasons.  Valgrind might be a useful tool here.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Optimizer questions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Refactoring speculative insertion with unique indexes a little