[postgis-devel] [postgis-users] Oddity in _ST_Expand(geography) ?

[Pavan Deolasee]

On Wed, Jul 4, 2018 at 4:49 PM, Darafei "Komяpa" Praliaskouski <
me at komzpa.net> wrote:

> Does this mean that at very least the function should for now be marked as
> PARALLEL RESRLTRICTED so that in case of parallel query value never goed
> through serialization?
>
>
I thought this is a good point and spent fair amount of time today trying
to reproduce the problem with parallel query execution without much
success. At the end, I noticed that XL has modified _outConst() to use
"out" function of the given type and on the remote node use "in" function
to parse the value back to its type, whereas the default code in PG simply
writes out the datum as a sequence of 4 byte integer and do the reverse
while reading it back. So the problem does not occur in plan
serialisation/deserialisation in parallel query path since when the datum
is written as sequence of integers, the bounding box info is written too.

I am not yet quite sure why we chose to take a different approach in XL,
and unfortunately code in that area is not well documented. But I suspect
that this is probably required because in XL every node is a Postgres
instance on its own, and the types can be logically different on each node.
Reverting back to the default PG code does not make XL happy.

While I look at the XL side more carefully and see if we can revert back to
PG's behaviour, I still believe this is a problem that we should fix on the
PostGIS side (too). AFAIK in PostgreSQL we assume that out/in functions
should safely convert a value to a string and back to its in-memory
representation. So keeping that guarantee for the "geography" data type
seems like the right thing to do.

Thanks,
Pavan

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180705/bf098d03/attachment-0001.html>