On 10/24/14, 3:26 PM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 3:30 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
On 10/24/14, 2:23 PM, Jim Nasby wrote:
On the serialization structure itself, should we be worried about a
mismatch between available GUCs on the sender vs the receiver? Presumably if
the sender outputs a GUC that the receiver doesn't know about we'll get an
error, but what if the sender didn't include something? Maybe not an issue
today, but could this cause problems down the road if we wanted to use the
serialized data some other way? But maybe I'm just being paranoid. :)
I just realized there's a bigger problem there; this isn't portable against
any changes to any of the binary elements.
So I guess it's really a question of would we ever want this to function
(as-is) cross-version.
I think that would be pretty hard to make work, but I don't mind if
someone else wants to try for some use case that they want to meet.
My goal is to make parallel query work, so the data will just be
getting transferred between two simultaneously-running children of the
same postmaster.
The only case I can think of would be actually connecting to a remote database;
in that case would we even want something as raw as this? I suspect not, in
which case I don't see an issue. On the other hand, if we ever think we might
want to do that, we should probably at least stick a version number field in
there...
But my suspicion is if we ever wanted to do something more with this then we'd
want some kind of text-based format that could be passed into a SQL command
(ie: SET ENVIRONMENT TO blah;)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
