Skip site navigation (1) Skip section navigation (2)

Re: Binary in/out for aclitem

From: rsmogura <rsmogura(at)softperience(dot)eu>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Binary in/out for aclitem
Date: 2011-02-24 15:03:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
 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.


In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-02-24 15:06:17
Subject: Re: Review: Fix snapshot taking inconsistencies
Previous:From: Merlin MoncureDate: 2011-02-24 14:38:35
Subject: Re: Binary in/out for aclitem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group