Re: [HACKERS] psql \d+ and oid display
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 br...@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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
On Wed, Apr 9, 2014 at 11:42 AM, Bruce Momjian br...@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 t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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 br...@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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml new file mode 100644 index 0b08f83..ac6a4a4 *** a/doc/src/sgml/ref/alter_table.sgml --- b/doc/src/sgml/ref/alter_table.sgml *** ALTER TABLE [ IF EXISTS ] replaceable c *** 608,619 para This form changes the information which is written to the write-ahead log to identify rows which are updated or deleted. This option has no effect ! except when logical replication is in use. literalDEFAULT/ records the old values of the columns of the primary key, if any. literalUSING INDEX/ records the old values of the columns covered by the named index, which must be unique, not partial, not deferrable, and include only columns marked literalNOT NULL/. literalFULL/ records the old values of all columns in the row. literalNOTHING/ records no information about the old row. In all cases, no old values are logged unless at least one of the columns that would be logged differs between the old and new versions of the row. /para --- 608,621 para This form changes the information which is written to the write-ahead log to identify rows which are updated or deleted. This option has no effect ! except when logical replication is in use. literalDEFAULT/ ! (the default for non-system tables) records the old values of the columns of the primary key, if any. literalUSING INDEX/ records the old values of the columns covered by the named index, which must be unique, not partial, not deferrable, and include only columns marked literalNOT NULL/. literalFULL/ records the old values of all columns in the row. literalNOTHING/ records no information about the old row. + (This is the default for system tables.) In all cases, no old values are logged unless at least one of the columns that would be logged differs between the old and new versions of the row. /para diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index 85899d7..0b91d45 *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** testdb=gt; *** 951,957 The command form literal\d+/literal is identical, except that more information is displayed: any comments associated with the columns of the table are shown, as is the presence of OIDs in the ! table, the view definition if the relation is a view. /para para --- 951,959 The command form literal\d+/literal is identical, except that more information is displayed: any comments associated with the columns of the table are shown, as is the presence of OIDs in the ! table, the view definition if the relation is a view, a non-default ! link linkend=SQL-CREATETABLE-REPLICA-IDENTITYreplica ! identity/link setting. /para para diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c new file mode 100644 index d1447fe..0ff7950 *** a/src/bin/psql/describe.c --- b/src/bin/psql/describe.c *** describeOneTableDetails(const char *sche *** 2350,2357 * No need to display default values; we already display a *
Re: [HACKERS] psql \d+ and oid display
Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote: Bruce Momjian br...@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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
On Wed, Apr 9, 2014 at 01:02:05AM -0400, Tom Lane wrote: Robert Haas robertmh...@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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote: On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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'))) -- Bruce Momjian br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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 t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Tue, Apr 8, 2014 at 05:29:45PM -0400, Tom Lane wrote: Bruce Momjian br...@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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
* Tom Lane (t...@sss.pgh.pa.us) wrote: Bruce Momjian br...@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 signature.asc Description: Digital signature
Re: [HACKERS] psql \d+ and oid display
On Tue, Apr 8, 2014 at 5:37 PM, Bruce Momjian br...@momjian.us wrote: On Tue, Apr 8, 2014 at 05:29:45PM -0400, Tom Lane wrote: Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian br...@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 br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
Robert Haas robertmh...@gmail.com writes: On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Tue, Apr 1, 2014 at 12:09 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Tue, Apr 1, 2014 at 8:42 AM, Bruce Momjian br...@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? 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. Cheers, Jeff
Re: [HACKERS] psql \d+ and oid display
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 br...@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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
new file mode 100644
index d1447fe..22b643f
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeOneTableDetails(const char *sche
*** 2365,2378
}
/* OIDs, if verbose and not a materialized view */
! if (verbose tableinfo.relkind != 'm')
! {
! const char *s = _(Has OIDs);
!
! printfPQExpBuffer(buf, %s: %s, s,
! (tableinfo.hasoids ? _(yes) : _(no)));
! printTableAddFooter(cont, buf.data);
! }
/* Tablespace info */
add_tablespace_footer(cont, tableinfo.relkind, tableinfo.tablespace,
--- 2365,2372
}
/* OIDs, if verbose and not a materialized view */
! if (verbose tableinfo.relkind != 'm' tableinfo.hasoids)
! printTableAddFooter(cont, _(Has OIDs: yes));
/* Tablespace info */
add_tablespace_footer(cont, tableinfo.relkind, tableinfo.tablespace,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
On Mar 28, 2014, at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@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
Re: [HACKERS] psql \d+ and oid display
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 t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
new file mode 100644
index 21bbdf8..a5bf5c9
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeOneTableDetails(const char *sche
*** 2362,2375
}
/* OIDs, if verbose and not a materialized view */
! if (verbose tableinfo.relkind != 'm')
! {
! const char *s = _(Has OIDs);
!
! printfPQExpBuffer(buf, %s: %s, s,
! (tableinfo.hasoids ? _(yes) : _(no)));
! printTableAddFooter(cont, buf.data);
! }
/* Tablespace info */
add_tablespace_footer(cont, tableinfo.relkind, tableinfo.tablespace,
--- 2362,2369
}
/* OIDs, if verbose and not a materialized view */
! if (verbose tableinfo.relkind != 'm' tableinfo.hasoids)
! printTableAddFooter(cont, _(Has OIDs));
/* Tablespace info */
add_tablespace_footer(cont, tableinfo.relkind, tableinfo.tablespace,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
Bruce Momjian wrote On Fri, Mar 28, 2014 at 03:53:32PM -0300, Fabrízio de Royes Mello wrote: On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane 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
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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
Re: [HACKERS] psql \d+ and oid display
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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
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
Re: [HACKERS] psql \d+ and oid display
Bruce Momjian br...@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
Re: [HACKERS] psql \d+ and oid display
On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote: Bruce Momjian br...@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 br...@momjian.ushttp://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
Re: [HACKERS] psql \d+ and oid display
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote: * Euler Taveira (eu...@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 br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c new file mode 100644 index 21bbdf8..367cb97 *** a/src/bin/psql/describe.c --- b/src/bin/psql/describe.c *** describeOneTableDetails(const char *sche *** 1169,1174 --- 1169,1175 bool hasrules; bool hastriggers; bool hasoids; + bool default_with_oids; Oid tablespace; char *reloptions; char *reloftype; *** describeOneTableDetails(const char *sche *** 1194,1199 --- 1195,1201 printfPQExpBuffer(buf, SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, c.relhastriggers, c.relhasoids, + (SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, %s, c.reltablespace, CASE WHEN c.reloftype = 0 THEN '' ELSE c.reloftype::pg_catalog.regtype::pg_catalog.text END, c.relpersistence, c.relreplident\n *** describeOneTableDetails(const char *sche *** 1211,1216 --- 1213,1219 printfPQExpBuffer(buf, SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, c.relhastriggers, c.relhasoids, + (SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, %s, c.reltablespace, CASE WHEN c.reloftype = 0 THEN '' ELSE c.reloftype::pg_catalog.regtype::pg_catalog.text END, c.relpersistence\n *** describeOneTableDetails(const char *sche *** 1228,1233 --- 1231,1237 printfPQExpBuffer(buf, SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, c.relhastriggers, c.relhasoids, + (SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, %s, c.reltablespace, CASE WHEN c.reloftype = 0 THEN '' ELSE c.reloftype::pg_catalog.regtype::pg_catalog.text END\n FROM pg_catalog.pg_class c\n *** describeOneTableDetails(const char *sche *** 1244,1249 --- 1248,1254 printfPQExpBuffer(buf, SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, c.relhastriggers, c.relhasoids, + (SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, %s, c.reltablespace\n FROM pg_catalog.pg_class c\n LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid)\n *** describeOneTableDetails(const char *sche *** 1259,1264 --- 1264,1270 printfPQExpBuffer(buf, SELECT relchecks, relkind, relhasindex, relhasrules, reltriggers 0, relhasoids, + (SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, %s, reltablespace\n FROM pg_catalog.pg_class WHERE oid = '%s';, (verbose ? *** describeOneTableDetails(const char *sche *** 1270,1275 --- 1276,1282 printfPQExpBuffer(buf, SELECT relchecks, relkind, relhasindex, relhasrules, reltriggers 0, relhasoids, + (SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, '', reltablespace\n FROM pg_catalog.pg_class WHERE oid = '%s';, oid); *** describeOneTableDetails(const char *sche *** 1279,1284 --- 1286,1292 printfPQExpBuffer(buf,
Re: [HACKERS] psql \d+ and oid display
Bruce Momjian br...@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
Re: [HACKERS] psql \d+ and oid display
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@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
Timbira: http://www.timbira.com.br
Blog sobre TI: http://fabriziomello.blogspot.com
Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
Twitter: http://twitter.com/fabriziomello
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 21bbdf8..ae5b740 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -2362,12 +2362,11 @@ describeOneTableDetails(const char *schemaname,
}
/* OIDs, if verbose and not a materialized view */
- if (verbose tableinfo.relkind != 'm')
+ if (verbose tableinfo.relkind != 'm' tableinfo.hasoids)
{
const char *s = _(Has OIDs);
- printfPQExpBuffer(buf, %s: %s, s,
- (tableinfo.hasoids ? _(yes) : _(no)));
+ printfPQExpBuffer(buf, %s: %s, s, _(yes));
printTableAddFooter(cont, buf.data);
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \d+ and oid display
* Tom Lane (t...@sss.pgh.pa.us) wrote: Bruce Momjian br...@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 signature.asc Description: Digital signature
[HACKERS] 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 br...@momjian.ushttp://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
Re: [HACKERS] 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
Re: [HACKERS] psql \d+ and oid display
* Euler Taveira (eu...@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 signature.asc Description: Digital signature
Re: [HACKERS] psql \d+ and oid display
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
Re: [HACKERS] psql \d+ and oid display
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
Re: [HACKERS] psql \d+ and oid display
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
