Re: psql \d+ and oid display

Bruce Momjian wrote
> On Fri, Mar 28, 2014 at 03:53:32PM -0300, Fabrízio de Royes Mello wrote:
>> On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane <

> tgl(at)(dot)pa

> > wrote:
>> >
>> > Bruce Momjian <

> bruce@

> > writes:
>> > > On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
>> > >> I believe Bruce was suggesting to show it when it is set to *not*
>> the
>> > >> default, which strikes me as perfectly reasonable.
>> >
>> > > We seem to be split on the idea of having "Has OIDs" display only
>> when
>> > > the oid status of the table does not match the default_with_oids
>> > > default.
>> >
>> > FWIW, I think that having the display depend on what that GUC is set to
>> > is a seriously *bad* idea. It will mean that you don't actually know,
>> > when looking at the output of \d, whether the table has OIDs or not.
>> >
>> > I could get behind a proposal to suppress the line when there are not
>> > OIDs, full stop; that is, we print either "Has OIDs: yes" or nothing.
>> > But I think this patch just makes things even more surprising when
>> > default_with_oids is turned on.
>> >
>>
>> Something like the attached ?
>
> I assume it would be more like my attachment, i.e. since we are only
> displaying it when OIDs exist, there is no value for oid status field
> --- just say "Has OIDs" or "Includes OIDs", or something like that.
>
> I know some people are saying there is no need to change the current
> output --- I am only saying that the importance of showing the lack of
> OIDs has lessened over the years, and we should reconsider its
> importance. If we reconsider and still think we are fine, that's good
> with me. I am saying we should not just keep doing this because we have
> always displayed it in the past.

As my belief is that 99% of the uses of \d are for human consumption
(because machines should in most cases hit the catalogs directly) then
strictly displaying "Includes OIDs" when appropriate has my +1.

Uses of \d+ in regression suites will be obvious and quickly fixed and
likely account for another 0.9%.

psql backslash commands are not machine API contracts and should be adapted
for optimal human consumption; thus neutering the argument for maintaining
backward compatibility.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/psql-d-and-oid-display-tp5797653p5797879.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.