On Wed, Feb 23, 2011 at 3:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > =?utf-8?q?Rados=C5=82aw_Smogura?= <rsmog...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
