On Wed, Feb 23, 2011 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Radosław Smogura <rsmogura@softperience.eu> writes:
>> Here is extended version, has version field (N_ACL_RIGHTS*2) and reserved
>> mask, as well definition is more general then def of PGSQL. In any way it
>> require that rights mades bit array.
>
> You're going in quite the wrong direction here. The consensus as I
> understood it was that we should just use the text representation in
> binary mode too, rather than inventing a separate representation that's
> going to put a whole new set of constraints on what can happen to the
> internal representation. The proposal you have here has no redeeming
> social value whatever, because nobody cares about the I/O efficiency
> for aclitem (and even if anyone did, you've made no case that this would
> actually be more efficient to use on the client side).
+1 on this. binary wire format is a win generally when one of the two
properties is true:
1) the receiving application is putting it into a binary structure
that is similar to what the backend sends, and conversion is
non-trivial (timestamps, geo types, etc)
2) text format needs lots of escaping (bytea, arrays etc)
Let's take the numeric type for example...if we were debating the
binary wire format for that type, I would be arguing for the backend
to send a string for the binary wire format unless someone could
present a solid case that the postgres format dropped right into a
popular numeric library in C, etc (AFAIK, it doesn't). Almost
everyone that gets a numeric will directly translate it to a string or
a hardware binary representation which the backend can't send.
Even if you could make the case for aclitem on performance grounds,
you still have to get past tom's objection (which I agree with) that
the performance benefit outweighs having to deal with making and
(especially) maintaining the binary wire format. It should be
becoming obvious to everyone the binary formats are becoming
increasingly popular, and sooner or later backwards compatibility
issues and other unresolved issues pertaining to them have to be dealt
with. Point being, let's not make that more difficult than it has to
be.
merlin
