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@.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
