psql \d+ and oid display

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, Suporte 24x7 e Treinamento

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 ?

Grettings,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 &lt;

tgl@.pa

&gt; wrote:

Bruce Momjian &lt;

bruce@

&gt; 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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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