Обсуждение: psql \d+ and oid display

When we made OIDs optional, we added an oid status display to \d+:
test=> \d+ test                         Table "public.test" Column |  Type   | Modifiers | Storage | Stats target |
Description--------+---------+-----------+---------+--------------+-------------x      | integer |           | plain
|             |
 
-->    Has OIDs: no

Do we want to continue displaying that OID line, or make it optional for
cases where the value doesn't match default_with_oids?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On 27-03-2014 10:15, Bruce Momjian wrote:
> When we made OIDs optional, we added an oid status display to \d+:
> 
>     test=> \d+ test
>                              Table "public.test"
>      Column |  Type   | Modifiers | Storage | Stats target | Description
>     --------+---------+-----------+---------+--------------+-------------
>      x      | integer |           | plain   |              |
> -->    Has OIDs: no
> 
> Do we want to continue displaying that OID line, or make it optional for
> cases where the value doesn't match default_with_oids?
> 
That line is still important for those tables that have oids. Once a
while I see "with oids" set (mainly by mistake or misinformation).

The 8.0 (last version that have default_with_oids = on) is dead for more
than 3 years. Is it time to remove the d_w_o or even announce to remove
it in 2 releases?

Regarding to remove the "Has OIDs" line, it seems that it is just noise
since almost all tables does not have oids. However, if you remove
that line you'll have to fix the regression tests and also can break
third part extensions that use \d+ (we can live with that). If we agree
to remove d_w_o, don't worry with that line because it will be removed soon.


--   Euler Taveira                   Timbira - http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 

* Euler Taveira (euler@timbira.com.br) wrote:
> On 27-03-2014 10:15, Bruce Momjian wrote:
> > When we made OIDs optional, we added an oid status display to \d+:
> >
> >     test=> \d+ test
> >                              Table "public.test"
> >      Column |  Type   | Modifiers | Storage | Stats target | Description
> >     --------+---------+-----------+---------+--------------+-------------
> >      x      | integer |           | plain   |              |
> > -->    Has OIDs: no
> >
> > Do we want to continue displaying that OID line, or make it optional for
> > cases where the value doesn't match default_with_oids?
> >
> That line is still important for those tables that have oids. Once a
> while I see "with oids" set (mainly by mistake or misinformation).

I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.

If the default is "without OIDs", then this will show on tables which
*have* OIDs.  And vice-versa.

> The 8.0 (last version that have default_with_oids = on) is dead for more
> than 3 years. Is it time to remove the d_w_o or even announce to remove
> it in 2 releases?

I don't know that we need to drop the option...

> Regarding to remove the "Has OIDs" line, it seems that it is just noise
> since almost all tables does not have oids. However, if you remove
> that line you'll have to fix the regression tests and also can break
> third part extensions that use \d+ (we can live with that). If we agree
> to remove d_w_o, don't worry with that line because it will be removed soon.

I expect there are products which are still using it...
Thanks,
    Stephen

Bruce Momjian wrote
> When we made OIDs optional, we added an oid status display to \d+:
> 
>     test=> \d+ test
>                              Table "public.test"
>      Column |  Type   | Modifiers | Storage | Stats target | Description
>     --------+---------+-----------+---------+--------------+-------------
>      x      | integer |           | plain   |              |
> -->    Has OIDs: no
> 
> Do we want to continue displaying that OID line, or make it optional for
> cases where the value doesn't match default_with_oids?

If we didn't make it behave this way at the time of the change then what has
changed that we should make it behave this way now?  I like the logic
generally but not necessarily the change.  

The disadvantage of this change is users (both end and tools) of the data
now also have to look at what the default is (or was at the time the text
was generated) to know what a suppressed OIDs means.  Given how much
information the typical \d+ generates I would suspect that the added noise
this introduces is quickly ignored by frequent users and not all the
disruptive to those who use \d+ infrequently.  Tools likely would prefer is
to be always displayed.

My $0.02

David J.




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

On 03/27/2014 04:43 PM, David Johnston wrote:
> Bruce Momjian wrote
>> When we made OIDs optional, we added an oid status display to \d+:
>>
>>     test=> \d+ test
>>                              Table "public.test"
>>      Column |  Type   | Modifiers | Storage | Stats target | Description
>>     --------+---------+-----------+---------+--------------+-------------
>>      x      | integer |           | plain   |              |
>> -->    Has OIDs: no
>>
>> Do we want to continue displaying that OID line, or make it optional for
>> cases where the value doesn't match default_with_oids?
> If we didn't make it behave this way at the time of the change then what has
> changed that we should make it behave this way now?  I like the logic
> generally but not necessarily the change.
>
> The disadvantage of this change is users (both end and tools) of the data
> now also have to look at what the default is (or was at the time the text
> was generated) to know what a suppressed OIDs means.  Given how much
> information the typical \d+ generates I would suspect that the added noise
> this introduces is quickly ignored by frequent users and not all the
> disruptive to those who use \d+ infrequently.  Tools likely would prefer is
> to be always displayed.
>
>


Frankly, to me it's just useless noise.

cheers

andrew

On 2014-03-27 09:15:52 -0400, Bruce Momjian wrote:
> When we made OIDs optional, we added an oid status display to \d+:
> 
>     test=> \d+ test
>                              Table "public.test"
>      Column |  Type   | Modifiers | Storage | Stats target | Description
>     --------+---------+-----------+---------+--------------+-------------
>      x      | integer |           | plain   |              |
> -->    Has OIDs: no
> 
> Do we want to continue displaying that OID line, or make it optional for
> cases where the value doesn't match default_with_oids?

I think we should just leave this alone. Changing this seems useless
noise at this point.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
> * Euler Taveira (euler@timbira.com.br) wrote:
> > On 27-03-2014 10:15, Bruce Momjian wrote:
> > > When we made OIDs optional, we added an oid status display to \d+:
> > >
> > >     test=> \d+ test
> > >                              Table "public.test"
> > >      Column |  Type   | Modifiers | Storage | Stats target | Description
> > >     --------+---------+-----------+---------+--------------+-------------
> > >      x      | integer |           | plain   |              |
> > > -->    Has OIDs: no
> > >
> > > Do we want to continue displaying that OID line, or make it optional for
> > > cases where the value doesn't match default_with_oids?
> > >
> > That line is still important for those tables that have oids. Once a
> > while I see "with oids" set (mainly by mistake or misinformation).
>
> 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.

I am attaching a patch which implements this, but given no consensus, I
will not apply it unless we can be more definite.

My motivation was that "Has OIDs" was important when we stopped having
an oid column by default, but at this point many users don't even know
what OIDs are and the line is potentially confusing and mostly useless.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Bruce Momjian <bruce@momjian.us> 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.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Bruce Momjian <bruce@momjian.us> 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.

Good point- I don't really consider that a parameter that people change,
but there probably are folks out there who do change it.

> 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.

Works for me.
Thanks,
    Stephen

On Mar 28, 2014, at 2:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> 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.

Agreed.

> 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.

I see little reason to tinker with the status quo.

...Robert

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@sss.pgh.pa.us> wrote:
> >
> > Bruce Momjian <bruce@momjian.us> 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.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

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.

On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
> 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.

One other issue --- we are adding conditional display of "Replica
Identity" to psql \d+ in 9.4, so users processing \d+ output are already
going to have to make adjustments for 9.4.  That is another reason I am
asking about this now.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On 03/29/2014 04:49 PM, Bruce Momjian wrote:
> On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
>> 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.
> One other issue --- we are adding conditional display of "Replica
> Identity" to psql \d+ in 9.4, so users processing \d+ output are already
> going to have to make adjustments for 9.4.  That is another reason I am
> asking about this now.
>


I think Tom's suggestion probably has the most support, although it's 
not unanimous.

cheers

andrew

On Sat, Mar 29, 2014 at 05:10:49PM -0400, Andrew Dunstan wrote:
> 
> On 03/29/2014 04:49 PM, Bruce Momjian wrote:
> >On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
> >>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.
> >One other issue --- we are adding conditional display of "Replica
> >Identity" to psql \d+ in 9.4, so users processing \d+ output are already
> >going to have to make adjustments for 9.4.  That is another reason I am
> >asking about this now.
> >
> 
> 
> I think Tom's suggestion probably has the most support, although
> it's not unanimous.

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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On 03/29/2014 06:10 PM, Bruce Momjian wrote:
> On Sat, Mar 29, 2014 at 05:10:49PM -0400, Andrew Dunstan wrote:
>> On 03/29/2014 04:49 PM, Bruce Momjian wrote:
>>> On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
>>>> 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.
>>> One other issue --- we are adding conditional display of "Replica
>>> Identity" to psql \d+ in 9.4, so users processing \d+ output are already
>>> going to have to make adjustments for 9.4.  That is another reason I am
>>> asking about this now.
>>>
>>
>> I think Tom's suggestion probably has the most support, although
>> it's not unanimous.
> 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.
>

1. _a_ line.
2. Don't make it dependent on the GUC. If the table has OIDS then say 
so, if not, say nothing.

As to majority size, I have no idea.

cheers

andrew

Bruce Momjian <bruce@momjian.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".
        regards, tom lane

On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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).

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

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@momjian.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.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian <bruce@momjian.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@momjian.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

On Tue, Apr  1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
> > 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.

Well, there are lot of _other_ things we could display about the table
that we don't.  Are you suggesting we add those too?  What about
"Replica Identity"?  Should that always display?

The bottom line is we already have complex rules to display only what is
_reasonable_.  If you want everything, you have to look at the system
tables.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Apr  1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
>> > 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.
>
> Well, there are lot of _other_ things we could display about the table
> that we don't.  Are you suggesting we add those too?  What about
> "Replica Identity"?  Should that always display?

In \d+, I think it absolutely should.

> The bottom line is we already have complex rules to display only what is
> _reasonable_.  If you want everything, you have to look at the system
> tables.

I don't really agree with that.  I understand that there's some
information (like dependencies) that you can't get through psql
because we don't really have a principled idea for what an interface
to that would look like, but I don't think that's a good thing.  Every
time I have to write a query by hand to get some information instead
of being able to get it through a backslash command, that slows me
down considerably.  But I'm lucky in that I actually know enough to do
that, which most users don't.  Information that you can't get through
\d+ just isn't available to a large percentage of our user base
without huge effort.  We shouldn't be stingy about putting stuff in
there that people may need to see.

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

Bruce Momjian <bruce@momjian.us> writes:
> On Tue, Apr  1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
>> 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.

> Well, there are lot of _other_ things we could display about the table
> that we don't.  Are you suggesting we add those too?  What about
> "Replica Identity"?  Should that always display?

> The bottom line is we already have complex rules to display only what is
> _reasonable_.  If you want everything, you have to look at the system
> tables.

Yeah.  All of the \d commands are compromises between verbosity and
displaying all needful information, so I don't think that Robert's
proposed approach is particularly helpful.  It would only lead to
requests for \d-plus-one-half mode once people realized that "everything"
is too much.  (I'd rather go in the direction of \d++ yielding extra
info, if we ever decide to have more than two verbosity levels.)

I do think there's some merit to the argument about "it's been like
this for years, why change it?".  But if you reject backwards
compatibility as an overriding factor here, the currently-proposed
patch seems the sanest design to me.
        regards, tom lane

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> The bottom line is we already have complex rules to display only what is
>> _reasonable_.  If you want everything, you have to look at the system
>> tables.

> I don't really agree with that.  I understand that there's some
> information (like dependencies) that you can't get through psql
> because we don't really have a principled idea for what an interface
> to that would look like, but I don't think that's a good thing.  Every
> time I have to write a query by hand to get some information instead
> of being able to get it through a backslash command, that slows me
> down considerably.  But I'm lucky in that I actually know enough to do
> that, which most users don't.  Information that you can't get through
> \d+ just isn't available to a large percentage of our user base
> without huge effort.  We shouldn't be stingy about putting stuff in
> there that people may need to see.

At least in this particular case, that's an uninteresting argument.
We aren't being stingy with information, because the proposed new display
approach provides *exactly the same information* as before.  (If you see
the "Has OIDs" line, it's got OIDs, otherwise it doesn't.)  What we are
being stingy about is display clutter, and I believe that's a good thing.
        regards, tom lane

On Tue, Apr 1, 2014 at 12:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>> The bottom line is we already have complex rules to display only what is
>>> _reasonable_.  If you want everything, you have to look at the system
>>> tables.
>
>> I don't really agree with that.  I understand that there's some
>> information (like dependencies) that you can't get through psql
>> because we don't really have a principled idea for what an interface
>> to that would look like, but I don't think that's a good thing.  Every
>> time I have to write a query by hand to get some information instead
>> of being able to get it through a backslash command, that slows me
>> down considerably.  But I'm lucky in that I actually know enough to do
>> that, which most users don't.  Information that you can't get through
>> \d+ just isn't available to a large percentage of our user base
>> without huge effort.  We shouldn't be stingy about putting stuff in
>> there that people may need to see.
>
> At least in this particular case, that's an uninteresting argument.
> We aren't being stingy with information, because the proposed new display
> approach provides *exactly the same information* as before.  (If you see
> the "Has OIDs" line, it's got OIDs, otherwise it doesn't.)  What we are
> being stingy about is display clutter, and I believe that's a good thing.

Although I agree with the general principle, I'm skeptical in this
case.  There are a bunch of table-level options, and I don't think
it's very reasonable to expect that users are going to remember which
ones are going to be displayed under which conditions, especially if
we change it from release to release.  If somebody doesn't see the
"has OIDs" line, are they going to conclude that the table doesn't
have OIDs, or are they going to conclude that psql doesn't ever
display that information and they need to query pg_class manually?
I'm sure at least some people will guess wrong.

Now, admittedly, this is not the hill I want to die on.  The future of
PostgreSQL doesn't rest on whatever ends up happening here.  But I
think what's going on on this thread is a lot of tinkering with stuff
that's not really broken.  I'm not saying "don't ever change psql
output".  What I'm saying is that changing psql output that is
absolutely fine the way it is does not represent meaningful progress.
The "replica identity" and "has OIDs" lines are a negligible
percentage of what \d+ spits out - in a test I just did, 2 out of 37
lines on \d+ pg_class.  I can't accept that tinkering with that is
reducing clutter in any meaningful way; it's just change for the sake
of change.

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

On 2014-04-01 13:36:02 -0400, Robert Haas wrote:
> I can't accept that tinkering with that is
> reducing clutter in any meaningful way; it's just change for the sake
> of change.

+1

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

On Tue, Apr  1, 2014 at 01:36:02PM -0400, Robert Haas wrote:
> Although I agree with the general principle, I'm skeptical in this
> case.  There are a bunch of table-level options, and I don't think
> it's very reasonable to expect that users are going to remember which
> ones are going to be displayed under which conditions, especially if
> we change it from release to release.  If somebody doesn't see the
> "has OIDs" line, are they going to conclude that the table doesn't
> have OIDs, or are they going to conclude that psql doesn't ever
> display that information and they need to query pg_class manually?
> I'm sure at least some people will guess wrong.
> 
> Now, admittedly, this is not the hill I want to die on.  The future of
> PostgreSQL doesn't rest on whatever ends up happening here.  But I
> think what's going on on this thread is a lot of tinkering with stuff
> that's not really broken.  I'm not saying "don't ever change psql
> output".  What I'm saying is that changing psql output that is
> absolutely fine the way it is does not represent meaningful progress.
> The "replica identity" and "has OIDs" lines are a negligible
> percentage of what \d+ spits out - in a test I just did, 2 out of 37
> lines on \d+ pg_class.  I can't accept that tinkering with that is
> reducing clutter in any meaningful way; it's just change for the sake
> of change.

I looked over the psql code and Robert is right that "Has OIDs" and
"Identity Replica" are the only two cases where we are printing status,
rather than unique strings like an index name.  The only example I could
find was where we print "Number of child tables" in \d when there are
child tables.  Of course, we print the child table names when they exist
in \d+, but we don't print "No child tables" with \d or \d+, which seems
logical.

If we ignore backward compatibility, then "Has OIDs" and "Identity
Replica" are similar.  One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the mention of OIDs or "Identity Replica" than will actually care about
these features.  For example, if we always printed "Child tables: 0",
more people would be confused than helped.

I don't think there is enough other cases for \d++ to make sense.

I am not sure where to go from here.  One idea would be tally the people
who have commented in this thread, but a more thorough approach would
be to have a vote.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

Bruce Momjian <bruce@momjian.us> writes:
> If we ignore backward compatibility, then "Has OIDs" and "Identity
> Replica" are similar.  One thing that strongly (for me) supports not
> always printing them is that I expect more people will be confused by
> the mention of OIDs or "Identity Replica" than will actually care about
> these features.  For example, if we always printed "Child tables: 0",
> more people would be confused than helped.

This is a good argument, actually: these fields are not only noise for
most people, but confusing if you don't know the feature they are
talking about.
        regards, tom lane

On Tue, Apr  8, 2014 at 05:29:45PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > If we ignore backward compatibility, then "Has OIDs" and "Identity
> > Replica" are similar.  One thing that strongly (for me) supports not
> > always printing them is that I expect more people will be confused by
> > the mention of OIDs or "Identity Replica" than will actually care about
> > these features.  For example, if we always printed "Child tables: 0",
> > more people would be confused than helped.
> 
> This is a good argument, actually: these fields are not only noise for
> most people, but confusing if you don't know the feature they are
> talking about.

Let me put it this way:  I didn't know what "Identity Replica" meant
when I saw it in psql.  Now, some might say that is expected, but still. ;-)

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > If we ignore backward compatibility, then "Has OIDs" and "Identity
> > Replica" are similar.  One thing that strongly (for me) supports not
> > always printing them is that I expect more people will be confused by
> > the mention of OIDs or "Identity Replica" than will actually care about
> > these features.  For example, if we always printed "Child tables: 0",
> > more people would be confused than helped.
>
> This is a good argument, actually: these fields are not only noise for
> most people, but confusing if you don't know the feature they are
> talking about.

I concur with this and would rather they not be there.  One of the
things that annoys me about certain other RDBMS's is how darn verbose
they are- it makes trying to read the definitions require much
head-scratching.

I'm on the fence about a \d++.  In general, I get a bit annoyed when
certain information isn't available through the backslash commands, but
it's hard to justify another '+' level for just these.
Thanks,
    Stephen

On Tue, Apr 8, 2014 at 5:37 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Apr  8, 2014 at 05:29:45PM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>> > If we ignore backward compatibility, then "Has OIDs" and "Identity
>> > Replica" are similar.  One thing that strongly (for me) supports not
>> > always printing them is that I expect more people will be confused by
>> > the mention of OIDs or "Identity Replica" than will actually care about
>> > these features.  For example, if we always printed "Child tables: 0",
>> > more people would be confused than helped.
>>
>> This is a good argument, actually: these fields are not only noise for
>> most people, but confusing if you don't know the feature they are
>> talking about.
>
> Let me put it this way:  I didn't know what "Identity Replica" meant
> when I saw it in psql.  Now, some might say that is expected, but still. ;-)

Well, that's sorta my concern.  I mean, right now we've got people
saying "what the heck is a replica identity?".  But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way.  I haven't studied
the current code in detail so maybe it's fine.  I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.

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

Robert Haas <robertmhaas@gmail.com> writes:
> Well, that's sorta my concern.  I mean, right now we've got people
> saying "what the heck is a replica identity?".  But, if the logical
> decoding stuff becomes popular, as I hope it will, that's going to be
> an important thing for people to adjust, and the information needs to
> be present in a clear and easily-understood way.  I haven't studied
> the current code in detail so maybe it's fine.  I just want to make
> sure we're not giving it second-class treatment solely on the basis
> that it's new and people aren't using it yet.

I think the proposal is "don't mention the property if it has the
default value".  That's not second-class status, as long as people
who know what the property is understand that behavior.  It's just
conserving screen space.
        regards, tom lane

On Wed, Apr  9, 2014 at 01:02:05AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Well, that's sorta my concern.  I mean, right now we've got people
> > saying "what the heck is a replica identity?".  But, if the logical
> > decoding stuff becomes popular, as I hope it will, that's going to be
> > an important thing for people to adjust, and the information needs to
> > be present in a clear and easily-understood way.  I haven't studied
> > the current code in detail so maybe it's fine.  I just want to make
> > sure we're not giving it second-class treatment solely on the basis
> > that it's new and people aren't using it yet.
> 
> I think the proposal is "don't mention the property if it has the
> default value".  That's not second-class status, as long as people
> who know what the property is understand that behavior.  It's just
> conserving screen space.

Yes, the lines will certainly appear if you have set _anything_ as
non-default, both oids and replica identity.  Kind of the same as how we
show indexes and child tables if any exist (it is non-default), and
unlogged tables.

I know I have fielded questions during training asking, "What is that
OID line?", so I do know it confuses people.  It does give me a chance
to talk about it, but based on how often it is useful, I am not sure
that is a win.

Ideally we would deal with oids for 9.5, but since I think everyone
agrees that replica identity and oids should behave the same, we need to
decide this for 9.4.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Well, that's sorta my concern.  I mean, right now we've got people
>> saying "what the heck is a replica identity?".  But, if the logical
>> decoding stuff becomes popular, as I hope it will, that's going to be
>> an important thing for people to adjust, and the information needs to
>> be present in a clear and easily-understood way.  I haven't studied
>> the current code in detail so maybe it's fine.  I just want to make
>> sure we're not giving it second-class treatment solely on the basis
>> that it's new and people aren't using it yet.
>
> I think the proposal is "don't mention the property if it has the
> default value".  That's not second-class status, as long as people
> who know what the property is understand that behavior.  It's just
> conserving screen space.

One thing that concerns me is that replica identity has a different
default for system tables (NOTHING) than for other tables (DEFAULT).
So when we say we're not going to display the default value, are we
going to display it when it's not NOTHING, when it's not DEFAULT, or
when it's not the actual default for that particular kind of table?

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

On Wed, Apr  9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> Well, that's sorta my concern.  I mean, right now we've got people
> >> saying "what the heck is a replica identity?".  But, if the logical
> >> decoding stuff becomes popular, as I hope it will, that's going to be
> >> an important thing for people to adjust, and the information needs to
> >> be present in a clear and easily-understood way.  I haven't studied
> >> the current code in detail so maybe it's fine.  I just want to make
> >> sure we're not giving it second-class treatment solely on the basis
> >> that it's new and people aren't using it yet.
> >
> > I think the proposal is "don't mention the property if it has the
> > default value".  That's not second-class status, as long as people
> > who know what the property is understand that behavior.  It's just
> > conserving screen space.
> 
> One thing that concerns me is that replica identity has a different
> default for system tables (NOTHING) than for other tables (DEFAULT).
> So when we say we're not going to display the default value, are we
> going to display it when it's not NOTHING, when it's not DEFAULT, or
> when it's not the actual default for that particular kind of table?

We exclude pg_catalog from displaying Replica Identity due to this
inconsistency.  I assume this was desired because you can't replicate
system tables.  Is that true?  The current test is:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&    /*     * No need to display default values;  we
alreadydisplay a     * REPLICA IDENTITY marker on indexes.     */    tableinfo.relreplident != 'd' &&
tableinfo.relreplident!= 'i' &&    strcmp(schemaname, "pg_catalog") != 0)
 

What might make more sense is this:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&    /*     * No need to display default values;  we
alreadydisplay 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')))
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On 2014-04-09 11:42:32 -0400, Bruce Momjian wrote:
> On Wed, Apr  9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
> > On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > Robert Haas <robertmhaas@gmail.com> writes:
> > >> Well, that's sorta my concern.  I mean, right now we've got people
> > >> saying "what the heck is a replica identity?".  But, if the logical
> > >> decoding stuff becomes popular, as I hope it will, that's going to be
> > >> an important thing for people to adjust, and the information needs to
> > >> be present in a clear and easily-understood way.  I haven't studied
> > >> the current code in detail so maybe it's fine.  I just want to make
> > >> sure we're not giving it second-class treatment solely on the basis
> > >> that it's new and people aren't using it yet.
> > >
> > > I think the proposal is "don't mention the property if it has the
> > > default value".  That's not second-class status, as long as people
> > > who know what the property is understand that behavior.  It's just
> > > conserving screen space.
> > 
> > One thing that concerns me is that replica identity has a different
> > default for system tables (NOTHING) than for other tables (DEFAULT).
> > So when we say we're not going to display the default value, are we
> > going to display it when it's not NOTHING, when it's not DEFAULT, or
> > when it's not the actual default for that particular kind of table?
> 
> We exclude pg_catalog from displaying Replica Identity due to this
> inconsistency.

I don't understand why it's inconsistent, but whatever.

> I assume this was desired because you can't replicate
> system tables.  Is that true?

Yes.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

On Wed, Apr 9, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Apr  9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
>> On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > Robert Haas <robertmhaas@gmail.com> writes:
>> >> Well, that's sorta my concern.  I mean, right now we've got people
>> >> saying "what the heck is a replica identity?".  But, if the logical
>> >> decoding stuff becomes popular, as I hope it will, that's going to be
>> >> an important thing for people to adjust, and the information needs to
>> >> be present in a clear and easily-understood way.  I haven't studied
>> >> the current code in detail so maybe it's fine.  I just want to make
>> >> sure we're not giving it second-class treatment solely on the basis
>> >> that it's new and people aren't using it yet.
>> >
>> > I think the proposal is "don't mention the property if it has the
>> > default value".  That's not second-class status, as long as people
>> > who know what the property is understand that behavior.  It's just
>> > conserving screen space.
>>
>> One thing that concerns me is that replica identity has a different
>> default for system tables (NOTHING) than for other tables (DEFAULT).
>> So when we say we're not going to display the default value, are we
>> going to display it when it's not NOTHING, when it's not DEFAULT, or
>> when it's not the actual default for that particular kind of table?
>
> We exclude pg_catalog from displaying Replica Identity due to this
> inconsistency.  I assume this was desired because you can't replicate
> system tables.  Is that true?  The current test is:
>
>         if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
>             /*
>              * No need to display default values;  we already display a
>              * REPLICA IDENTITY marker on indexes.
>              */
>             tableinfo.relreplident != 'd' && tableinfo.relreplident != 'i' &&
>             strcmp(schemaname, "pg_catalog") != 0)
>
> 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.

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

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. +

<p dir="ltr">If it's conditional I think "when it matches a guc" is too hard for users to use.<p dir="ltr">I think "say
nothingif oids are off and say something of their on" would be fine. It would result in clutter for users which oids on
bydefault but that's a non default setting. <p dir="ltr">And the consequences of having oids on when they're intended
tobe 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'llsurely notice...<p dir="ltr">-- <br /> greg<div class="gmail_quote">On 10 Apr 2014 12:45, "Bruce Momjian" <<a
href="mailto:bruce@momjian.us">bruce@momjian.us</a>>wrote:<br type="attribution" /><blockquote class="gmail_quote"
style="margin:00 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, Apr 10, 2014 at 12:23:40PM -0400, Robert
Haaswrote:<br /> > > What might make more sense is this:<br /> > ><br /> > >         if
((tableinfo.relkind== 'r' || tableinfo.relkind == 'm') &&<br /> > >             /*<br /> > >      
      * No need to display default values;  we already display a<br /> > >              * REPLICA IDENTITY marker
onindexes.<br /> > >              */<br /> > >             tableinfo.relreplident != 'i' &&<br />
>>             ((strcmp(schemaname, "pg_catalog") != 0 && tableinfo.relreplident != 'd') ||<br /> >
>             (strcmp(schemaname, "pg_catalog") == 0 && tableinfo.relreplident != 'n')))<br /> ><br />
>Well, this is why I think we should just display it always.  I don't<br /> > think users are going to remember
theexact algorithm for whether or<br /> > not the line gets displayed, so you're just putting yourself in a<br />
>situation where the \d+ output doesn't actually inform the user.  If<br /> > you want to leave it out when it's
"default"and show the "none" line<br /> > for catalog tables, that's OK by me too.  But calling one line of<br />
>output that displays important information "clutter" and only appears<br /> > when the user explicitly requests
verbosemode (with \d+ rather than<br /> > \d) strikes me as as silly.<br /><br /> The issue is that "none" is the
defaultfor system tables and "default"<br /> is the default for user tables.  Tom complained about the "none" for
the<br/> pg_depend display.<br /><br /> I am starting to think I am not going to make everyone happy and we just<br />
needto vote.  Frankly, I think there are enough people who want this<br /> conditionally displayed that I don't even
needa vote.<br /><br /> --<br />   Bruce Momjian  <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>>      
 <ahref="http://momjian.us" target="_blank">http://momjian.us</a><br />   EnterpriseDB                             <a
href="http://enterprisedb.com"target="_blank">http://enterprisedb.com</a><br /><br />   + Everyone has their own god.
+<br/><br /><br /> --<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></blockquote></div> 

On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote:
> If it's conditional I think "when it matches a guc" is too hard for users to
> use.

Yes, we gave up on having the OID display match the GUC;  we just
display something if and only if it oids are present.

Robert is talking about the "Identity Replica" display, which is new in
9.4 and should match how we display oids.  Right now "Identity Replica"
only displays something if the user changed the default.

> 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.

Yes, that is what the proposed patch does.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Tue, Apr  1, 2014 at 10:45:29AM -0700, Jeff Janes wrote:
> I am suggesting it for at least some other things.  I'm rather aggrieved that "
> \d+" without argument shows you the size and the description/comment for every
> table, but "\d+ foo" does not show you the size and description/comment of the
> specific table you just asked for.
> 
> Not so aggrieved that I wrote and submitted a patch, you might notice; but I'll
> get to it eventually if no one beats me to it.

Agree, that is kind of odd.  Should that be a TODO?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Thu, Apr 10, 2014 at 01:10:35PM -0400, Bruce Momjian wrote:
> On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote:
> > If it's conditional I think "when it matches a guc" is too hard for users to
> > use.
>
> Yes, we gave up on having the OID display match the GUC;  we just
> display something if and only if it oids are present.
>
> Robert is talking about the "Identity Replica" display, which is new in
> 9.4 and should match how we display oids.  Right now "Identity Replica"
> only displays something if the user changed the default.
>
> > 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.
>
> Yes, that is what the proposed patch does.

I talked to Robert via voice to understand his concerns.  He clearly
explained the complexity of how "Replica Identity" is set.  I, of
course, am concerned about user confusion in showing these values.

What I did was develop the attached patch which clarifies the default
for system and non-system tables, documents when psql displays it, and
improves the display for pg_catalog tables that aren't equal to NONE.

It also has changed the OID status to only display if it exists.  One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when present.

I am hopeful this patch is closer to general agreement.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Bruce Momjian <bruce@momjian.us> writes:
> It also has changed the OID status to only display if it exists.  One
> question that came up with Robert is whether OID status should appear
> for \d as well, now that is only shows up when present.

Yeah, I was wondering about that too.  If part of the argument here is
to make these two displays act more alike, it seems inconsistent that
one is emitted by \d while the other only comes out with \d+.

Of course, there are two ways to fix that: maybe the replica info
also only belongs in \d+?
        regards, tom lane

On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > It also has changed the OID status to only display if it exists.  One
> > question that came up with Robert is whether OID status should appear
> > for \d as well, now that is only shows up when present.
> 
> Yeah, I was wondering about that too.  If part of the argument here is
> to make these two displays act more alike, it seems inconsistent that
> one is emitted by \d while the other only comes out with \d+.
> 
> Of course, there are two ways to fix that: maybe the replica info
> also only belongs in \d+?

OK, I changed my patch to only show replica info for \d+.  If we decide
to change them to both display for \d, I will update it again.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

On Thu, Apr 10, 2014 at 08:05:11PM -0400, Bruce Momjian wrote:
> On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > It also has changed the OID status to only display if it exists.  One
> > > question that came up with Robert is whether OID status should appear
> > > for \d as well, now that is only shows up when present.
> > 
> > Yeah, I was wondering about that too.  If part of the argument here is
> > to make these two displays act more alike, it seems inconsistent that
> > one is emitted by \d while the other only comes out with \d+.
> > 
> > Of course, there are two ways to fix that: maybe the replica info
> > also only belongs in \d+?
> 
> OK, I changed my patch to only show replica info for \d+.  If we decide
> to change them to both display for \d, I will update it again.

OK, hearing only quiet, I have applied the patch.  I like that we now
document the replication identity default, which should go a long way to
making this clearer.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +