On Thu, 24 Feb 2011 08:38:35 -0600, Merlin Moncure wrote:
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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
