Re: Binary in/out for aclitem

On Thu, 24 Feb 2011 08:38:35 -0600, Merlin Moncure wrote:
> On Wed, Feb 23, 2011 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> =?utf-8?q?Rados=C5=82aw_Smogura?= <rsmogura(at)softperience(dot)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

Thanks, but actually I didn't realized final direction, "pass to text"
or "create something really extensive", I didn't treat aclitem IO as
live or dead case, just all. I always treat performance really serious,
but I'm not psychopathic to check aclitem IO!!!

Btw, In my opinion binary format will be popular not for speed, but for
that it is internal strict, and pass in many situations more useful
informations (e.g. types for structs, arrays), it is just easier to
maintain on driver side. But it is still unpopular maybe due to missing
methods :), and few others.

Regards,
Radek