From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb and nested hstore |
Date: | 2014-02-10 19:07:35 |
Message-ID: | CAHyXU0xN3YZDDyj4x_PcbE2CmrTzMtg-5w3S2VpoD54gb2=JGQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
>>>> Teodor privately suggested something similar. I was thinking of just
>>>> sending a version byte, which for now would be '\x01'. An int8 seems like
>>>> more future-proofing provision than we really need.
>
>> -1. Currently no other wire format types send version and it's not
>> clear why this one is special. We've changed the wire format versions
>> before and it's upon the client to deal with those changes.
>
> Really? How would you expect to do that, exactly? In particular,
> how would you propose that a binary pg_dump file be reloadable if
> we redefine the binary format down the road without having made
> provision like this?
>
>> Versioning one type only IMNSHO is a complete hack.
>
> I don't feel a need for versioning int, or float8, or most other types;
> and that includes the ones for which we've previously defined binary
> format as equivalent to text (enums). In this case we know that we're not
> totally satisfied with the binary format we're defining today, so I think
> a type-specific escape hatch is a reasonable solution.
>
> Moreover, I don't especially buy tying it to server version, even if we
> had an information pathway that would provide that reliably in all
> contexts.
Why not? Furthermore what are we doing now? If we need a binary
format contract that needs to be separated from this discussion.
I've written (along with Andrew C) the only serious attempt to deal
with client side binary format handling (http://libpqtypes.esilo.com/)
and in all interesting cases it depends on the server version to
define binary parsing behaviors. I agree WRT float8, etc but other
types have changed in a couple of cases and it's always been with the
version. I find it highly unlikely that any compatibility behaviors
are going to be defined *for each and every returned datum* now, or
ever...so even if it's a few bytes lost, why do it? Intra-version
compatibility issues should they ever have to be handled would be more
likely handled at connection- or query- time.
Point being, if an escape hatch is needed, I'm near 100% certain this
is not the right place to do it. Binary wire format compatibility is
a complex topic and proposed solution ISTM is not at all fleshed out.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2014-02-10 19:55:38 | Re: [HACKERS] GSoC 2014 - mentors, students and admins |
Previous Message | Alexander Korotkov | 2014-02-10 18:59:48 | Re: PoC: Partial sort |