If it's conditional I think "when it matches a guc" is too hard for users to use.
I think "say nothing if oids are off and say something of their on" would be fine. It would result in clutter for users which oids on by default but that's a non default setting.
And the consequences of having oids on when they're intended to be off are much more likely to be missed our forgotten and need a reminder. If they're off when they need to be on you'll surely notice...
--
greg
On 10 Apr 2014 12:45, "Bruce Momjian" <
bruce@momjian.us> wrote:
On Thu, Apr 10, 2014 at 12:23:40PM -0400, Robert Haas wrote:
> > What might make more sense is this:
> >
> > if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
> > /*
> > * No need to display default values; we already display a
> > * REPLICA IDENTITY marker on indexes.
> > */
> > tableinfo.relreplident != 'i' &&
> > ((strcmp(schemaname, "pg_catalog") != 0 && tableinfo.relreplident != 'd') ||
> > (strcmp(schemaname, "pg_catalog") == 0 && tableinfo.relreplident != 'n')))
>
> Well, this is why I think we should just display it always. I don't
> think users are going to remember the exact algorithm for whether or
> not the line gets displayed, so you're just putting yourself in a
> situation where the \d+ output doesn't actually inform the user. If
> you want to leave it out when it's "default" and show the "none" line
> for catalog tables, that's OK by me too. But calling one line of
> output that displays important information "clutter" and only appears
> when the user explicitly requests verbose mode (with \d+ rather than
> \d) strikes me as as silly.
The issue is that "none" is the default for system tables and "default"
is the default for user tables. Tom complained about the "none" for the
pg_depend display.
I am starting to think I am not going to make everyone happy and we just
need to vote. Frankly, I think there are enough people who want this
conditionally displayed that I don't even need a vote.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
