Re: psql \d+ and oid display

On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Sat, Mar 29, 2014 at 06:33:39PM -0400, Bruce Momjian wrote:
>> On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
>> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > > Are you saying most people like "Has OIDs: yes", or the idea of just
>> > > displaying _a_ line if there are OIDs? Based on default_with_oids,
>> > > perhaps we should display "With OIDs".
>> >
>> > > I agree it is no unanimous. I am curious how large the majority has to
>> > > be to change a psql display value.
>> >
>> > What I actually suggested was not *changing* the line when it's to be
>> > displayed, but suppressing it in the now-standard case where there's no
>> > OIDs.
>> >
>> > Personally I find the argument that backwards compatibility must be
>> > preserved to be pretty bogus; we have no hesitation in changing the
>> > output of \d anytime we add a new feature. So I don't think there's
>> > a good compatibility reason why the line has to be spelled exactly
>> > "Has OIDs: yes" --- but there is a consistency reason, which is that
>> > everything else we print in this part of the \d output is of the form
>> > "label: info".
>>
>> Ah, now I understand it --- you can argue that the new "Replica
>> Identity" follows the same pattern, showing only for non-defaults (or at
>> least it will once I commit the pending patch to do that).
>
> OK, I have now applied the conditional display of "Replica Identity"
> patch (which is how it was originally coded anyway). The attached patch
> matches Tom's suggestion of displaying the same OID text, just
> conditionally.
>
> Seeing psql \d+ will have a conditional display line in PG 9.4, making
> OIDs conditional seems to make sense.

Frankly, I think this is all completely wrong-headed. \d+ should
display *everything*. That's what the + means, isn't it? Coming up
with complex rules for which things get shown and which things get
hidden just makes the output harder to understand, without any
compensating benefit.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company