On 10/24/14, 3:26 PM, Robert Haas wrote:
> On Fri, Oct 24, 2014 at 3:30 PM, Jim Nasby <Jim.Nasby@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
somethingas raw as this? I suspect not, in which case I don't see an issue. On the other hand, if we ever think we
mightwant 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
couldbe 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
