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

Re: Binary in/out for aclitem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Radosław Smogura <rsmogura(at)softperience(dot)eu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Binary in/out for aclitem
Date: 2011-02-23 01:20:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It'd be more future-proof than this patch, but I'm still unconvinced
>> about the use-case.

> Do we want to intentionally make binary format a second-class citizen?

Well, it's not exactly a first-class citizen; compare for instance the
amount of verbiage in the docs about text I/O formats versus the amount
about binary formats.  But my question isn't about that; it's about why
aclitem should be considered a first-class citizen.  It makes me
uncomfortable that client apps are looking at it at all, because any
that do are bound to get broken in the future, even assuming that they
get the right answers today.  I wonder how many such clients are up to
speed for per-column privileges and non-constant default privileges for
instance.  And sepgsql is going to cut them off at the knees.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Itagaki TakahiroDate: 2011-02-23 01:42:16
Subject: psql tab-completion for CREATE UNLOGGED TABLE
Previous:From: Robert HaasDate: 2011-02-23 01:18:24
Subject: Re: Snapshot synchronization, again...

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