psql \d+ and oid display
When we made OIDs optional, we added an oid status display to \d+:
test=> \d+ test
Table "public.test"
Column | Type | Modifiers | Storage | Stats target | Description
--------+---------+-----------+---------+--------------+-------------
x | integer | | plain | |
--> Has OIDs: no
Do we want to continue displaying that OID line, or make it optional for
cases where the value doesn't match default_with_oids?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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: noDo 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: noDo 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: noDo 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: noDo 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: noDo 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: noDo 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. +
Attachments:
oid.difftext/x-diff; charset=us-asciiDownload
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,
"SELECT relchecks, relkind, relhasindex, relhasrules, "
"reltriggers <> 0, relhasoids, "
+ "(SELECT setting FROM pg_settings WHERE name = 'default_with_oids') AS default_with_oids, "
"'', ''\n"
"FROM pg_catalog.pg_class WHERE oid = '%s';",
oid);
*************** describeOneTableDetails(const char *sche
*** 1302,1318 ****
tableinfo.hasrules = strcmp(PQgetvalue(res, 0, 3), "t") == 0;
tableinfo.hastriggers = strcmp(PQgetvalue(res, 0, 4), "t") == 0;
tableinfo.hasoids = strcmp(PQgetvalue(res, 0, 5), "t") == 0;
tableinfo.reloptions = (pset.sversion >= 80200) ?
! pg_strdup(PQgetvalue(res, 0, 6)) : NULL;
tableinfo.tablespace = (pset.sversion >= 80000) ?
! atooid(PQgetvalue(res, 0, 7)) : 0;
tableinfo.reloftype = (pset.sversion >= 90000 &&
! strcmp(PQgetvalue(res, 0, 8), "") != 0) ?
! pg_strdup(PQgetvalue(res, 0, 8)) : NULL;
tableinfo.relpersistence = (pset.sversion >= 90100) ?
! *(PQgetvalue(res, 0, 9)) : 0;
tableinfo.relreplident = (pset.sversion >= 90400) ?
! *(PQgetvalue(res, 0, 10)) : 'd';
PQclear(res);
res = NULL;
--- 1310,1327 ----
tableinfo.hasrules = strcmp(PQgetvalue(res, 0, 3), "t") == 0;
tableinfo.hastriggers = strcmp(PQgetvalue(res, 0, 4), "t") == 0;
tableinfo.hasoids = strcmp(PQgetvalue(res, 0, 5), "t") == 0;
+ tableinfo.default_with_oids = strcmp(PQgetvalue(res, 0, 6), "t") == 0;
tableinfo.reloptions = (pset.sversion >= 80200) ?
! pg_strdup(PQgetvalue(res, 0, 7)) : NULL;
tableinfo.tablespace = (pset.sversion >= 80000) ?
! atooid(PQgetvalue(res, 0, 8)) : 0;
tableinfo.reloftype = (pset.sversion >= 90000 &&
! strcmp(PQgetvalue(res, 0, 9), "") != 0) ?
! pg_strdup(PQgetvalue(res, 0, 9)) : NULL;
tableinfo.relpersistence = (pset.sversion >= 90100) ?
! *(PQgetvalue(res, 0, 10)) : 0;
tableinfo.relreplident = (pset.sversion >= 90400) ?
! *(PQgetvalue(res, 0, 11)) : 'd';
PQclear(res);
res = NULL;
*************** describeOneTableDetails(const char *sche
*** 2362,2368 ****
}
/* OIDs, if verbose and not a materialized view */
! if (verbose && tableinfo.relkind != 'm')
{
const char *s = _("Has OIDs");
--- 2371,2378 ----
}
/* OIDs, if verbose and not a materialized view */
! if (verbose && tableinfo.relkind != 'm' &&
! tableinfo.hasoids != tableinfo.default_with_oids)
{
const char *s = _("Has OIDs");
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
Show quoted text
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
Attachments:
display_oids_v1.patchtext/x-diff; charset=US-ASCII; name=display_oids_v1.patchDownload
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);
}
* 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. +
Attachments:
oid.difftext/x-diff; charset=us-asciiDownload
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,
Bruce Momjian wrote
On Fri, Mar 28, 2014 at 03:53:32PM -0300, Fabrízio de Royes Mello wrote:
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane <
tgl@.pa
> wrote:
Bruce Momjian <
bruce@
> writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not*
the
default, which strikes me as perfectly reasonable.
We seem to be split on the idea of having "Has OIDs" display only
when
the oid status of the table does not match the default_with_oids
default.FWIW, I think that having the display depend on what that GUC is set to
is a seriously *bad* idea. It will mean that you don't actually know,
when looking at the output of \d, whether the table has OIDs or not.I could get behind a proposal to suppress the line when there are not
OIDs, full stop; that is, we print either "Has OIDs: yes" or nothing.
But I think this patch just makes things even more surprising when
default_with_oids is turned on.Something like the attached ?
I assume it would be more like my attachment, i.e. since we are only displaying it when OIDs exist, there is no value for oid status field --- just say "Has OIDs" or "Includes OIDs", or something like that.I know some people are saying there is no need to change the current
output --- I am only saying that the importance of showing the lack of
OIDs has lessened over the years, and we should reconsider its
importance. If we reconsider and still think we are fine, that's good
with me. I am saying we should not just keep doing this because we have
always displayed it in the past.
As my belief is that 99% of the uses of \d are for human consumption
(because machines should in most cases hit the catalogs directly) then
strictly displaying "Includes OIDs" when appropriate has my +1.
Uses of \d+ in regression suites will be obvious and quickly fixed and
likely account for another 0.9%.
psql backslash commands are not machine API contracts and should be adapted
for optimal human consumption; thus neutering the argument for maintaining
backward compatibility.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/psql-d-and-oid-display-tp5797653p5797879.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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. +
Attachments:
oid.difftext/x-diff; charset=us-asciiDownload
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,
On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Sat, Mar 29, 2014 at 06:33:39PM -0400, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Are you saying most people like "Has OIDs: yes", or the idea of just
displaying _a_ line if there are OIDs? Based on default_with_oids,
perhaps we should display "With OIDs".I agree it is no unanimous. I am curious how large the majority has to
be to change a psql display value.What I actually suggested was not *changing* the line when it's to be
displayed, but suppressing it in the now-standard case where there's no
OIDs.Personally I find the argument that backwards compatibility must be
preserved to be pretty bogus; we have no hesitation in changing the
output of \d anytime we add a new feature. So I don't think there's
a good compatibility reason why the line has to be spelled exactly
"Has OIDs: yes" --- but there is a consistency reason, which is that
everything else we print in this part of the \d output is of the form
"label: info".Ah, now I understand it --- you can argue that the new "Replica
Identity" follows the same pattern, showing only for non-defaults (or at
least it will once I commit the pending patch to do that).OK, I have now applied the conditional display of "Replica Identity"
patch (which is how it was originally coded anyway). The attached patch
matches Tom's suggestion of displaying the same OID text, just
conditionally.Seeing psql \d+ will have a conditional display line in PG 9.4, making
OIDs conditional seems to make sense.
Frankly, I think this is all completely wrong-headed. \d+ should
display *everything*. That's what the + means, isn't it? Coming up
with complex rules for which things get shown and which things get
hidden just makes the output harder to understand, without any
compensating benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of "Replica Identity"
patch (which is how it was originally coded anyway). The attached patch
matches Tom's suggestion of displaying the same OID text, just
conditionally.Seeing psql \d+ will have a conditional display line in PG 9.4, making
OIDs conditional seems to make sense.Frankly, I think this is all completely wrong-headed. \d+ should
display *everything*. That's what the + means, isn't it? Coming up
with complex rules for which things get shown and which things get
hidden just makes the output harder to understand, without any
compensating benefit.
Well, there are lot of _other_ things we could display about the table
that we don't. Are you suggesting we add those too? What about
"Replica Identity"? Should that always display?
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything, you have to look at the system
tables.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of "Replica Identity"
patch (which is how it was originally coded anyway). The attached patch
matches Tom's suggestion of displaying the same OID text, just
conditionally.Seeing psql \d+ will have a conditional display line in PG 9.4, making
OIDs conditional seems to make sense.Frankly, I think this is all completely wrong-headed. \d+ should
display *everything*. That's what the + means, isn't it? Coming up
with complex rules for which things get shown and which things get
hidden just makes the output harder to understand, without any
compensating benefit.Well, there are lot of _other_ things we could display about the table
that we don't. Are you suggesting we add those too? What about
"Replica Identity"? Should that always display?
In \d+, I think it absolutely should.
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything, you have to look at the system
tables.
I don't really agree with that. I understand that there's some
information (like dependencies) that you can't get through psql
because we don't really have a principled idea for what an interface
to that would look like, but I don't think that's a good thing. Every
time I have to write a query by hand to get some information instead
of being able to get it through a backslash command, that slows me
down considerably. But I'm lucky in that I actually know enough to do
that, which most users don't. Information that you can't get through
\d+ just isn't available to a large percentage of our user base
without huge effort. We shouldn't be stingy about putting stuff in
there that people may need to see.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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:
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
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything, you have to look at the system
tables.
I don't really agree with that. I understand that there's some
information (like dependencies) that you can't get through psql
because we don't really have a principled idea for what an interface
to that would look like, but I don't think that's a good thing. Every
time I have to write a query by hand to get some information instead
of being able to get it through a backslash command, that slows me
down considerably. But I'm lucky in that I actually know enough to do
that, which most users don't. Information that you can't get through
\d+ just isn't available to a large percentage of our user base
without huge effort. We shouldn't be stingy about putting stuff in
there that people may need to see.
At least in this particular case, that's an uninteresting argument.
We aren't being stingy with information, because the proposed new display
approach provides *exactly the same information* as before. (If you see
the "Has OIDs" line, it's got OIDs, otherwise it doesn't.) What we are
being stingy about is display clutter, and I believe that's a good thing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Apr 1, 2014 at 12:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything, you have to look at the system
tables.I don't really agree with that. I understand that there's some
information (like dependencies) that you can't get through psql
because we don't really have a principled idea for what an interface
to that would look like, but I don't think that's a good thing. Every
time I have to write a query by hand to get some information instead
of being able to get it through a backslash command, that slows me
down considerably. But I'm lucky in that I actually know enough to do
that, which most users don't. Information that you can't get through
\d+ just isn't available to a large percentage of our user base
without huge effort. We shouldn't be stingy about putting stuff in
there that people may need to see.At least in this particular case, that's an uninteresting argument.
We aren't being stingy with information, because the proposed new display
approach provides *exactly the same information* as before. (If you see
the "Has OIDs" line, it's got OIDs, otherwise it doesn't.) What we are
being stingy about is display clutter, and I believe that's a good thing.
Although I agree with the general principle, I'm skeptical in this
case. There are a bunch of table-level options, and I don't think
it's very reasonable to expect that users are going to remember which
ones are going to be displayed under which conditions, especially if
we change it from release to release. If somebody doesn't see the
"has OIDs" line, are they going to conclude that the table doesn't
have OIDs, or are they going to conclude that psql doesn't ever
display that information and they need to query pg_class manually?
I'm sure at least some people will guess wrong.
Now, admittedly, this is not the hill I want to die on. The future of
PostgreSQL doesn't rest on whatever ends up happening here. But I
think what's going on on this thread is a lot of tinkering with stuff
that's not really broken. I'm not saying "don't ever change psql
output". What I'm saying is that changing psql output that is
absolutely fine the way it is does not represent meaningful progress.
The "replica identity" and "has OIDs" lines are a negligible
percentage of what \d+ spits out - in a test I just did, 2 out of 37
lines on \d+ pg_class. I can't accept that tinkering with that is
reducing clutter in any meaningful way; it's just change for the sake
of change.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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-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
On Tue, Apr 1, 2014 at 8:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of "Replica Identity"
patch (which is how it was originally coded anyway). The attachedpatch
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
On Tue, Apr 1, 2014 at 01:36:02PM -0400, Robert Haas wrote:
Although I agree with the general principle, I'm skeptical in this
case. There are a bunch of table-level options, and I don't think
it's very reasonable to expect that users are going to remember which
ones are going to be displayed under which conditions, especially if
we change it from release to release. If somebody doesn't see the
"has OIDs" line, are they going to conclude that the table doesn't
have OIDs, or are they going to conclude that psql doesn't ever
display that information and they need to query pg_class manually?
I'm sure at least some people will guess wrong.Now, admittedly, this is not the hill I want to die on. The future of
PostgreSQL doesn't rest on whatever ends up happening here. But I
think what's going on on this thread is a lot of tinkering with stuff
that's not really broken. I'm not saying "don't ever change psql
output". What I'm saying is that changing psql output that is
absolutely fine the way it is does not represent meaningful progress.
The "replica identity" and "has OIDs" lines are a negligible
percentage of what \d+ spits out - in a test I just did, 2 out of 37
lines on \d+ pg_class. I can't accept that tinkering with that is
reducing clutter in any meaningful way; it's just change for the sake
of change.
I looked over the psql code and Robert is right that "Has OIDs" and
"Identity Replica" are the only two cases where we are printing status,
rather than unique strings like an index name. The only example I could
find was where we print "Number of child tables" in \d when there are
child tables. Of course, we print the child table names when they exist
in \d+, but we don't print "No child tables" with \d or \d+, which seems
logical.
If we ignore backward compatibility, then "Has OIDs" and "Identity
Replica" are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the mention of OIDs or "Identity Replica" than will actually care about
these features. For example, if we always printed "Child tables: 0",
more people would be confused than helped.
I don't think there is enough other cases for \d++ to make sense.
I am not sure where to go from here. One idea would be tally the people
who have commented in this thread, but a more thorough approach would
be to have a vote.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
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:
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
On Tue, Apr 8, 2014 at 05:29:45PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
If we ignore backward compatibility, then "Has OIDs" and "Identity
Replica" are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the mention of OIDs or "Identity Replica" than will actually care about
these features. For example, if we always printed "Child tables: 0",
more people would be confused than helped.This is a good argument, actually: these fields are not only noise for
most people, but confusing if you don't know the feature they are
talking about.
Let me put it this way: I didn't know what "Identity Replica" meant
when I saw it in psql. Now, some might say that is expected, but still. ;-)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Bruce Momjian <bruce@momjian.us> writes:
If we ignore backward compatibility, then "Has OIDs" and "Identity
Replica" are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the mention of OIDs or "Identity Replica" than will actually care about
these features. For example, if we always printed "Child tables: 0",
more people would be confused than helped.This is a good argument, actually: these fields are not only noise for
most people, but confusing if you don't know the feature they are
talking about.
I concur with this and would rather they not be there. One of the
things that annoys me about certain other RDBMS's is how darn verbose
they are- it makes trying to read the definitions require much
head-scratching.
I'm on the fence about a \d++. In general, I get a bit annoyed when
certain information isn't available through the backslash commands, but
it's hard to justify another '+' level for just these.
Thanks,
Stephen
On Tue, Apr 8, 2014 at 5:37 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Apr 8, 2014 at 05:29:45PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
If we ignore backward compatibility, then "Has OIDs" and "Identity
Replica" are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the mention of OIDs or "Identity Replica" than will actually care about
these features. For example, if we always printed "Child tables: 0",
more people would be confused than helped.This is a good argument, actually: these fields are not only noise for
most people, but confusing if you don't know the feature they are
talking about.Let me put it this way: I didn't know what "Identity Replica" meant
when I saw it in psql. Now, some might say that is expected, but still. ;-)
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.
I think the proposal is "don't mention the property if it has the
default value". That's not second-class status, as long as people
who know what the property is understand that behavior. It's just
conserving screen space.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 9, 2014 at 01:02:05AM -0400, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.I think the proposal is "don't mention the property if it has the
default value". That's not second-class status, as long as people
who know what the property is understand that behavior. It's just
conserving screen space.
Yes, the lines will certainly appear if you have set _anything_ as
non-default, both oids and replica identity. Kind of the same as how we
show indexes and child tables if any exist (it is non-default), and
unlogged tables.
I know I have fielded questions during training asking, "What is that
OID line?", so I do know it confuses people. It does give me a chance
to talk about it, but based on how often it is useful, I am not sure
that is a win.
Ideally we would deal with oids for 9.5, but since I think everyone
agrees that replica identity and oids should behave the same, we need to
decide this for 9.4.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.I think the proposal is "don't mention the property if it has the
default value". That's not second-class status, as long as people
who know what the property is understand that behavior. It's just
conserving screen space.
One thing that concerns me is that replica identity has a different
default for system tables (NOTHING) than for other tables (DEFAULT).
So when we say we're not going to display the default value, are we
going to display it when it's not NOTHING, when it's not DEFAULT, or
when it's not the actual default for that particular kind of table?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.I think the proposal is "don't mention the property if it has the
default value". That's not second-class status, as long as people
who know what the property is understand that behavior. It's just
conserving screen space.One thing that concerns me is that replica identity has a different
default for system tables (NOTHING) than for other tables (DEFAULT).
So when we say we're not going to display the default value, are we
going to display it when it's not NOTHING, when it's not DEFAULT, or
when it's not the actual default for that particular kind of table?
We exclude pg_catalog from displaying Replica Identity due to this
inconsistency. I assume this was desired because you can't replicate
system tables. Is that true? The current test is:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
/*
* No need to display default values; we already display a
* REPLICA IDENTITY marker on indexes.
*/
tableinfo.relreplident != 'd' && tableinfo.relreplident != 'i' &&
strcmp(schemaname, "pg_catalog") != 0)
What might make more sense is this:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
/*
* No need to display default values; we already display a
* REPLICA IDENTITY marker on indexes.
*/
tableinfo.relreplident != 'i' &&
((strcmp(schemaname, "pg_catalog") != 0 && tableinfo.relreplident != 'd') ||
(strcmp(schemaname, "pg_catalog") == 0 && tableinfo.relreplident != 'n')))
--
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 2014-04-09 11:42:32 -0400, Bruce Momjian wrote:
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.I think the proposal is "don't mention the property if it has the
default value". That's not second-class status, as long as people
who know what the property is understand that behavior. It's just
conserving screen space.One thing that concerns me is that replica identity has a different
default for system tables (NOTHING) than for other tables (DEFAULT).
So when we say we're not going to display the default value, are we
going to display it when it's not NOTHING, when it's not DEFAULT, or
when it's not the actual default for that particular kind of table?We exclude pg_catalog from displaying Replica Identity due to this
inconsistency.
I don't understand why it's inconsistent, but whatever.
I assume this was desired because you can't replicate
system tables. Is that true?
Yes.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 9, 2014 at 11:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, that's sorta my concern. I mean, right now we've got people
saying "what the heck is a replica identity?". But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the information needs to
be present in a clear and easily-understood way. I haven't studied
the current code in detail so maybe it's fine. I just want to make
sure we're not giving it second-class treatment solely on the basis
that it's new and people aren't using it yet.I think the proposal is "don't mention the property if it has the
default value". That's not second-class status, as long as people
who know what the property is understand that behavior. It's just
conserving screen space.One thing that concerns me is that replica identity has a different
default for system tables (NOTHING) than for other tables (DEFAULT).
So when we say we're not going to display the default value, are we
going to display it when it's not NOTHING, when it's not DEFAULT, or
when it's not the actual default for that particular kind of table?We exclude pg_catalog from displaying Replica Identity due to this
inconsistency. I assume this was desired because you can't replicate
system tables. Is that true? The current test is:if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
/*
* No need to display default values; we already display a
* REPLICA IDENTITY marker on indexes.
*/
tableinfo.relreplident != 'd' && tableinfo.relreplident != 'i' &&
strcmp(schemaname, "pg_catalog") != 0)What might make more sense is this:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
/*
* No need to display default values; we already display a
* REPLICA IDENTITY marker on indexes.
*/
tableinfo.relreplident != 'i' &&
((strcmp(schemaname, "pg_catalog") != 0 && tableinfo.relreplident != 'd') ||
(strcmp(schemaname, "pg_catalog") == 0 && tableinfo.relreplident != 'n')))
Well, this is why I think we should just display it always. I don't
think users are going to remember the exact algorithm for whether or
not the line gets displayed, so you're just putting yourself in a
situation where the \d+ output doesn't actually inform the user. If
you want to leave it out when it's "default" and show the "none" line
for catalog tables, that's OK by me too. But calling one line of
output that displays important information "clutter" and only appears
when the user explicitly requests verbose mode (with \d+ rather than
\d) strikes me as as silly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Apr 10, 2014 at 12:23:40PM -0400, Robert Haas wrote:
What might make more sense is this:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
/*
* No need to display default values; we already display a
* REPLICA IDENTITY marker on indexes.
*/
tableinfo.relreplident != 'i' &&
((strcmp(schemaname, "pg_catalog") != 0 && tableinfo.relreplident != 'd') ||
(strcmp(schemaname, "pg_catalog") == 0 && tableinfo.relreplident != 'n')))Well, this is why I think we should just display it always. I don't
think users are going to remember the exact algorithm for whether or
not the line gets displayed, so you're just putting yourself in a
situation where the \d+ output doesn't actually inform the user. If
you want to leave it out when it's "default" and show the "none" line
for catalog tables, that's OK by me too. But calling one line of
output that displays important information "clutter" and only appears
when the user explicitly requests verbose mode (with \d+ rather than
\d) strikes me as as silly.
The issue is that "none" is the default for system tables and "default"
is the default for user tables. Tom complained about the "none" for the
pg_depend display.
I am starting to think I am not going to make everyone happy and we just
need to vote. Frankly, I think there are enough people who want this
conditionally displayed that I don't even need a vote.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
If it's conditional I think "when it matches a guc" is too hard for users
to use.
I think "say nothing if oids are off and say something of their on" would
be fine. It would result in clutter for users which oids on by default but
that's a non default setting.
And the consequences of having oids on when they're intended to be off are
much more likely to be missed our forgotten and need a reminder. If they're
off when they need to be on you'll surely notice...
--
greg
On 10 Apr 2014 12:45, "Bruce Momjian" <bruce@momjian.us> wrote:
Show quoted text
On Thu, Apr 10, 2014 at 12:23:40PM -0400, Robert Haas wrote:
What might make more sense is this:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm') &&
/*
* No need to display default values; we already display a
* REPLICA IDENTITY marker on indexes.
*/
tableinfo.relreplident != 'i' &&
((strcmp(schemaname, "pg_catalog") != 0 &&tableinfo.relreplident != 'd') ||
(strcmp(schemaname, "pg_catalog") == 0 &&
tableinfo.relreplident != 'n')))
Well, this is why I think we should just display it always. I don't
think users are going to remember the exact algorithm for whether or
not the line gets displayed, so you're just putting yourself in a
situation where the \d+ output doesn't actually inform the user. If
you want to leave it out when it's "default" and show the "none" line
for catalog tables, that's OK by me too. But calling one line of
output that displays important information "clutter" and only appears
when the user explicitly requests verbose mode (with \d+ rather than
\d) strikes me as as silly.The issue is that "none" is the default for system tables and "default"
is the default for user tables. Tom complained about the "none" for the
pg_depend display.I am starting to think I am not going to make everyone happy and we just
need to vote. Frankly, I think there are enough people who want this
conditionally displayed that I don't even need a vote.--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote:
If it's conditional I think "when it matches a guc" is too hard for users to
use.
Yes, we gave up on having the OID display match the GUC; we just
display something if and only if it oids are present.
Robert is talking about the "Identity Replica" display, which is new in
9.4 and should match how we display oids. Right now "Identity Replica"
only displays something if the user changed the default.
I think "say nothing if oids are off and say something of their on" would be
fine. It would result in clutter for users which oids on by default but that's
a non default setting.
Yes, that is what the proposed patch does.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Apr 1, 2014 at 10:45:29AM -0700, Jeff Janes wrote:
I am suggesting it for at least some other things. I'm rather aggrieved that "
\d+" without argument shows you the size and the description/comment for every
table, but "\d+ foo" does not show you the size and description/comment of the
specific table you just asked for.Not so aggrieved that I wrote and submitted a patch, you might notice; but I'll
get to it eventually if no one beats me to it.
Agree, that is kind of odd. Should that be a TODO?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
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, Apr 10, 2014 at 01:10:35PM -0400, Bruce Momjian wrote:
On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote:
If it's conditional I think "when it matches a guc" is too hard for users to
use.Yes, we gave up on having the OID display match the GUC; we just
display something if and only if it oids are present.Robert is talking about the "Identity Replica" display, which is new in
9.4 and should match how we display oids. Right now "Identity Replica"
only displays something if the user changed the default.I think "say nothing if oids are off and say something of their on" would be
fine. It would result in clutter for users which oids on by default but that's
a non default setting.Yes, that is what the proposed patch does.
I talked to Robert via voice to understand his concerns. He clearly
explained the complexity of how "Replica Identity" is set. I, of
course, am concerned about user confusion in showing these values.
What I did was develop the attached patch which clarifies the default
for system and non-system tables, documents when psql displays it, and
improves the display for pg_catalog tables that aren't equal to NONE.
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when present.
I am hopeful this patch is closer to general agreement.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
psql.difftext/x-diff; charset=us-asciiDownload
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. <literal>DEFAULT</> records the
old values of the columns of the primary key, if any. <literal>USING 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
<literal>NOT NULL</>. <literal>FULL</> records the old values of all columns
in the row. <literal>NOTHING</> 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. <literal>DEFAULT</>
! (the default for non-system tables) records the
old values of the columns of the primary key, if any. <literal>USING 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
<literal>NOT NULL</>. <literal>FULL</> records the old values of all columns
in the row. <literal>NOTHING</> 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=>
*** 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-IDENTITY">replica
! 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
* REPLICA IDENTITY marker on indexes.
*/
! tableinfo.relreplident != 'd' && tableinfo.relreplident != 'i' &&
! strcmp(schemaname, "pg_catalog") != 0)
{
const char *s = _("Replica Identity");
--- 2350,2358 ----
* 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')))
{
const char *s = _("Replica Identity");
*************** 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,
--- 2366,2373 ----
}
/* 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,
diff --git a/src/test/regress/expected/create_table_like.out b/src/test/regress/expected/create_table_like.out
new file mode 100644
index 5f29b39..a5fac7b
*** a/src/test/regress/expected/create_table_like.out
--- b/src/test/regress/expected/create_table_like.out
*************** CREATE TABLE ctlt12_storage (LIKE ctlt1
*** 115,121 ****
a | text | not null | main | |
b | text | | extended | |
c | text | | external | |
- Has OIDs: no
CREATE TABLE ctlt12_comments (LIKE ctlt1 INCLUDING COMMENTS, LIKE ctlt2 INCLUDING COMMENTS);
\d+ ctlt12_comments
--- 115,120 ----
*************** CREATE TABLE ctlt12_comments (LIKE ctlt1
*** 125,131 ****
a | text | not null | extended | | A
b | text | | extended | | B
c | text | | extended | | C
- Has OIDs: no
CREATE TABLE ctlt1_inh (LIKE ctlt1 INCLUDING CONSTRAINTS INCLUDING COMMENTS) INHERITS (ctlt1);
NOTICE: merging column "a" with inherited definition
--- 124,129 ----
*************** NOTICE: merging constraint "ctlt1_a_che
*** 140,146 ****
Check constraints:
"ctlt1_a_check" CHECK (length(a) > 2)
Inherits: ctlt1
- Has OIDs: no
SELECT description FROM pg_description, pg_constraint c WHERE classoid = 'pg_constraint'::regclass AND objoid = c.oid AND c.conrelid = 'ctlt1_inh'::regclass;
description
--- 138,143 ----
*************** Check constraints:
*** 162,168 ****
"ctlt3_a_check" CHECK (length(a) < 5)
Inherits: ctlt1,
ctlt3
- Has OIDs: no
CREATE TABLE ctlt13_like (LIKE ctlt3 INCLUDING CONSTRAINTS INCLUDING COMMENTS INCLUDING STORAGE) INHERITS (ctlt1);
NOTICE: merging column "a" with inherited definition
--- 159,164 ----
*************** Check constraints:
*** 177,183 ****
"ctlt1_a_check" CHECK (length(a) > 2)
"ctlt3_a_check" CHECK (length(a) < 5)
Inherits: ctlt1
- Has OIDs: no
SELECT description FROM pg_description, pg_constraint c WHERE classoid = 'pg_constraint'::regclass AND objoid = c.oid AND c.conrelid = 'ctlt13_like'::regclass;
description
--- 173,178 ----
*************** Indexes:
*** 198,204 ****
"ctlt_all_expr_idx" btree ((a || b))
Check constraints:
"ctlt1_a_check" CHECK (length(a) > 2)
- Has OIDs: no
SELECT c.relname, objsubid, description FROM pg_description, pg_index i, pg_class c WHERE classoid = 'pg_class'::regclass AND objoid = i.indexrelid AND c.oid = i.indexrelid AND i.indrelid = 'ctlt_all'::regclass ORDER BY c.relname, objsubid;
relname | objsubid | description
--- 193,198 ----
diff --git a/src/test/regress/expected/foreign_data.out b/src/test/regress/expected/foreign_data.out
new file mode 100644
index c34c9b4..ff203b2
*** a/src/test/regress/expected/foreign_data.out
--- b/src/test/regress/expected/foreign_data.out
*************** COMMENT ON COLUMN ft1.c1 IS 'ft1.c1';
*** 684,690 ****
c3 | date | | | plain | |
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
- Has OIDs: no
\det+
List of foreign tables
--- 684,689 ----
*************** ALTER FOREIGN TABLE ft1 ALTER COLUMN c8
*** 743,749 ****
c10 | integer | | (p1 'v1') | plain | |
Server: s0
FDW Options: (delimiter ',', quote '"', "be quoted" 'value')
- Has OIDs: no
-- can't change the column type if it's used elsewhere
CREATE TABLE use_ft1_column_type (x ft1);
--- 742,747 ----
diff --git a/src/test/regress/expected/inherit.out b/src/test/regress/expected/inherit.out
new file mode 100644
index c84c435..56e2c99
*** a/src/test/regress/expected/inherit.out
--- b/src/test/regress/expected/inherit.out
*************** ALTER TABLE inhts RENAME d TO dd;
*** 913,919 ****
dd | integer | | plain | |
Inherits: inht1,
inhs1
- Has OIDs: no
DROP TABLE inhts;
-- Test for renaming in diamond inheritance
--- 913,918 ----
*************** ALTER TABLE inht1 RENAME aa TO aaa;
*** 934,940 ****
z | integer | | plain | |
Inherits: inht2,
inht3
- Has OIDs: no
CREATE TABLE inhts (d int) INHERITS (inht2, inhs1);
NOTICE: merging multiple inherited definitions of column "b"
--- 933,938 ----
*************** ERROR: cannot rename inherited column "
*** 952,958 ****
d | integer | | plain | |
Inherits: inht2,
inhs1
- Has OIDs: no
WITH RECURSIVE r AS (
SELECT 'inht1'::regclass AS inhrelid
--- 950,955 ----
*************** CREATE TABLE test_constraints_inh () INH
*** 999,1005 ****
Indexes:
"test_constraints_val1_val2_key" UNIQUE CONSTRAINT, btree (val1, val2)
Child tables: test_constraints_inh
- Has OIDs: no
ALTER TABLE ONLY test_constraints DROP CONSTRAINT test_constraints_val1_val2_key;
\d+ test_constraints
--- 996,1001 ----
*************** ALTER TABLE ONLY test_constraints DROP C
*** 1010,1016 ****
val1 | character varying | | extended | |
val2 | integer | | plain | |
Child tables: test_constraints_inh
- Has OIDs: no
\d+ test_constraints_inh
Table "public.test_constraints_inh"
--- 1006,1011 ----
*************** Has OIDs: no
*** 1020,1026 ****
val1 | character varying | | extended | |
val2 | integer | | plain | |
Inherits: test_constraints
- Has OIDs: no
DROP TABLE test_constraints_inh;
DROP TABLE test_constraints;
--- 1015,1020 ----
*************** CREATE TABLE test_ex_constraints_inh ()
*** 1037,1043 ****
Indexes:
"test_ex_constraints_c_excl" EXCLUDE USING gist (c WITH &&)
Child tables: test_ex_constraints_inh
- Has OIDs: no
ALTER TABLE test_ex_constraints DROP CONSTRAINT test_ex_constraints_c_excl;
\d+ test_ex_constraints
--- 1031,1036 ----
*************** ALTER TABLE test_ex_constraints DROP CON
*** 1046,1052 ****
--------+--------+-----------+---------+--------------+-------------
c | circle | | plain | |
Child tables: test_ex_constraints_inh
- Has OIDs: no
\d+ test_ex_constraints_inh
Table "public.test_ex_constraints_inh"
--- 1039,1044 ----
*************** Has OIDs: no
*** 1054,1060 ****
--------+--------+-----------+---------+--------------+-------------
c | circle | | plain | |
Inherits: test_ex_constraints
- Has OIDs: no
DROP TABLE test_ex_constraints_inh;
DROP TABLE test_ex_constraints;
--- 1046,1051 ----
*************** Indexes:
*** 1071,1077 ****
"test_primary_constraints_pkey" PRIMARY KEY, btree (id)
Referenced by:
TABLE "test_foreign_constraints" CONSTRAINT "test_foreign_constraints_id1_fkey" FOREIGN KEY (id1) REFERENCES test_primary_constraints(id)
- Has OIDs: no
\d+ test_foreign_constraints
Table "public.test_foreign_constraints"
--- 1062,1067 ----
*************** Has OIDs: no
*** 1081,1087 ****
Foreign-key constraints:
"test_foreign_constraints_id1_fkey" FOREIGN KEY (id1) REFERENCES test_primary_constraints(id)
Child tables: test_foreign_constraints_inh
- Has OIDs: no
ALTER TABLE test_foreign_constraints DROP CONSTRAINT test_foreign_constraints_id1_fkey;
\d+ test_foreign_constraints
--- 1071,1076 ----
*************** ALTER TABLE test_foreign_constraints DRO
*** 1090,1096 ****
--------+---------+-----------+---------+--------------+-------------
id1 | integer | | plain | |
Child tables: test_foreign_constraints_inh
- Has OIDs: no
\d+ test_foreign_constraints_inh
Table "public.test_foreign_constraints_inh"
--- 1079,1084 ----
*************** Has OIDs: no
*** 1098,1104 ****
--------+---------+-----------+---------+--------------+-------------
id1 | integer | | plain | |
Inherits: test_foreign_constraints
- Has OIDs: no
DROP TABLE test_foreign_constraints_inh;
DROP TABLE test_foreign_constraints;
--- 1086,1091 ----
diff --git a/src/test/regress/expected/rules.out b/src/test/regress/expected/rules.out
new file mode 100644
index b0b6e27..6c51d0d
*** a/src/test/regress/expected/rules.out
--- b/src/test/regress/expected/rules.out
*************** Rules:
*** 2609,2615 ****
r3 AS
ON DELETE TO rules_src DO
NOTIFY rules_src_deletion
- Has OIDs: no
--
-- check alter rename rule
--- 2609,2614 ----
Bruce Momjian <bruce@momjian.us> writes:
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when present.
Yeah, I was wondering about that too. If part of the argument here is
to make these two displays act more alike, it seems inconsistent that
one is emitted by \d while the other only comes out with \d+.
Of course, there are two ways to fix that: maybe the replica info
also only belongs in \d+?
regards, tom lane
--
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, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when present.Yeah, I was wondering about that too. If part of the argument here is
to make these two displays act more alike, it seems inconsistent that
one is emitted by \d while the other only comes out with \d+.Of course, there are two ways to fix that: maybe the replica info
also only belongs in \d+?
OK, I changed my patch to only show replica info for \d+. If we decide
to change them to both display for \d, I will update it again.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
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, Apr 10, 2014 at 08:05:11PM -0400, Bruce Momjian wrote:
On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when present.Yeah, I was wondering about that too. If part of the argument here is
to make these two displays act more alike, it seems inconsistent that
one is emitted by \d while the other only comes out with \d+.Of course, there are two ways to fix that: maybe the replica info
also only belongs in \d+?OK, I changed my patch to only show replica info for \d+. If we decide
to change them to both display for \d, I will update it again.
OK, hearing only quiet, I have applied the patch. I like that we now
document the replication identity default, which should go a long way to
making this clearer.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers