Re: [HACKERS] FWD: Re: Updated backslash consistency patch
Martin Pihlak writes: > Bruce Momjian wrote: >> Bruce Momjian wrote: >>> I know we don't like the current behavior, but I think we need to make >>> them consistent first for easy testing and so when we change it, it will >>> remain consistent. >>> >>> I will work on a consensus patch soon for the new behavior. >> > > The "\dXU *.*" commands also display objects from information_schema. IMHO > these should also be classified as system objects. It is most annoying to > run '\dfU *.*' and see a list of information_schema internal functions show > up. > Whereas the intent was to see the user defined functions in all schemas. You know I think I've come around to agreeing with one of Tom's proposals. I think we should do the following: \dX : list user objects \dXS : list system objects \dX : list all matching objects based on search_path \dX *.* : list all objects in all schemas I've basically come to the conclusion that having the output agree with behaviour at run-time is a big advantage and anything else would actually be too dangerous. If you do something like "\dt p*" or "\df a*" and are annoyed by the output you just have to make your pattern something more specific. For tables we already prefix them all with pg_ so one more letter ought to be enough. For functions it would be nice if we could trim the output quite a bit. I wonder if we could rename all our internal functions which implement operators and indexam methods without introducing any backwards compatibility issues. We don't document things like "int4gt" after all. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- 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] FWD: Re: Updated backslash consistency patch
Bruce Momjian wrote: > Bruce Momjian wrote: >> I know we don't like the current behavior, but I think we need to make >> them consistent first for easy testing and so when we change it, it will >> remain consistent. >> >> I will work on a consensus patch soon for the new behavior. > The "\dXU *.*" commands also display objects from information_schema. IMHO these should also be classified as system objects. It is most annoying to run '\dfU *.*' and see a list of information_schema internal functions show up. Whereas the intent was to see the user defined functions in all schemas. regards, Martin -- 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] FWD: Re: Updated backslash consistency patch
Dimitri Fontaine wrote: -- Start of PGP signed section. > Le mardi 20 janvier 2009, Bruce Momjian a ?crit?: > > Robert Haas wrote: > > > > Here is what I hope is a consensus patch. It adds 'A' to show all > > > > objects, including system ones. It turns out that this is how 'S' > > > > works now in CVS, but 'S' is unclear because it suggests just system > > > > objects; 'A' for show 'all' objects seems clearer. > > > > > > I think it's probably fine for "S" to mean "include system objects" > > > rather than "show only system objects". Everyone should be relatively > > > used to "S" by now; I think it's less confusing to keep the same > > > letter even if the behavior has been adjusted somewhat. Though others > > > may disagree? > > I still think that given a pattern, psql commands should simply mimic > whatever > is the server way of using search_path. I'd really like \df foo and \d foo to > follow the same rules as my production queries wrt to how to find objects > when I'm too lazy to schema qualify their name. > > Now, it's been advocated for the sake of simplicity to have with-pattern and > without-pattern options behave roughly the same way. I can't find it > difficult to explain the two behaviours here, all the more when looking at > current \d and \dt differences. The \d and \dt differences are fixed/gone in current CVS. > What I'd like to propose is for \df without pattern to behave exactly like \df > with pattern, *including* wrt to ordering the output. Functions listed in > search_path order, pg_catalog implicitly part of it, but as its *last* > element. Or whatever server object lookup code sayth. I personally liked the idea of searching pg_catalog for a pattern, but what turned me against it was this behavior: \d long list of user tables and then the user wants to see just the tables that begin with 'p': \d p* list of system and user tables that start with 'p' All of a sudden they see many system tables. It is hard to call that behavior logical or expected. One unusual approach would be to search pg_catalog only when a _non-wildcard_ pattern was supplied, so: \d p* would show user tables beginning with 'p', but: \d pg_class would find the 'pg_class' table that is the search path, typically from pg_catalog. It might be a little awkward to document, but might be the most acceptable solution. The very good argument _against_ this solution is that: \d pg_class* would show no rows while: \d pg_class would show the pg_catalog entry. This is also odd and unexpected, which led me to just having people use 'S' when they want pg_catalog involved. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] FWD: Re: Updated backslash consistency patch
Greg Sabino Mullane wrote: [ There is text before PGP section. ] > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > > > In thinking last night, I am now wondering if a letter is really the > > right symbol for this. We already have letter flags which control > > object type selection, but the system table addition is kind of > > independent of those flags, like '+' now. I am thinking maybe '&' is > > the right symbol rather than 'A' or 'S'. > > What problem are we trying to solve here that is not already solved by > using 'S' for system tables, which has been in use in psql for over a > decade now? Well, the 'S' behavior used to be only system, now it is _add_ system. Anyway, 'S' is still probably the best choice. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] FWD: Re: Updated backslash consistency patch
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > > In thinking last night, I am now wondering if a letter is really the > > right symbol for this. We already have letter flags which control > > object type selection, but the system table addition is kind of > > independent of those flags, like '+' now. I am thinking maybe '&' is > > the right symbol rather than 'A' or 'S'. > > & is probably going to be useful as a modifier when we have concurrent > psql, so I suggest you do not use it here. Or maybe not, but in any > case see > http://archives.postgresql.org/message-id/8204.1207689056%40sss.pgh.pa.us > before you use &. Yea, I thought '&' might be coming for that someday. I figured it wouldn't be used for backslash commands, but why confuse things. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] FWD: Re: Updated backslash consistency patch
Bruce, * Bruce Momjian (br...@momjian.us) wrote: > In thinking last night, I am now wondering if a letter is really the > right symbol for this. We already have letter flags which control > object type selection, but the system table addition is kind of > independent of those flags, like '+' now. I am thinking maybe '&' is > the right symbol rather than 'A' or 'S'. This really feels like over-engineering at this point. I don't particularly like '&', and 'S' has been in use like this for quite some time. Stephen signature.asc Description: Digital signature
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
Le mardi 20 janvier 2009, Bruce Momjian a écrit : > Robert Haas wrote: > > > Here is what I hope is a consensus patch. It adds 'A' to show all > > > objects, including system ones. It turns out that this is how 'S' > > > works now in CVS, but 'S' is unclear because it suggests just system > > > objects; 'A' for show 'all' objects seems clearer. > > > > I think it's probably fine for "S" to mean "include system objects" > > rather than "show only system objects". Everyone should be relatively > > used to "S" by now; I think it's less confusing to keep the same > > letter even if the behavior has been adjusted somewhat. Though others > > may disagree? I still think that given a pattern, psql commands should simply mimic whatever is the server way of using search_path. I'd really like \df foo and \d foo to follow the same rules as my production queries wrt to how to find objects when I'm too lazy to schema qualify their name. Now, it's been advocated for the sake of simplicity to have with-pattern and without-pattern options behave roughly the same way. I can't find it difficult to explain the two behaviours here, all the more when looking at current \d and \dt differences. What I'd like to propose is for \df without pattern to behave exactly like \df with pattern, *including* wrt to ordering the output. Functions listed in search_path order, pg_catalog implicitly part of it, but as its *last* element. Or whatever server object lookup code sayth. > '&' would stand for "and system objects". We could use '*' but that > might be confused with a wildcard symbol. If you insist on treating system object differently than server itself, I'd prefer for the client not to have me use well known non-alpha keys, which a lot of shells associate to e.g. jobs processing (bash, csh, lftp, some more I'm sure). Regards, -- dim signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > In thinking last night, I am now wondering if a letter is really the > right symbol for this. We already have letter flags which control > object type selection, but the system table addition is kind of > independent of those flags, like '+' now. I am thinking maybe '&' is > the right symbol rather than 'A' or 'S'. What problem are we trying to solve here that is not already solved by using 'S' for system tables, which has been in use in psql for over a decade now? - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200901201026 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkl17psACgkQvJuQZxSWSsjdRACgoAJPOBsWYPf420KLl/7tuPTa By0AoORZBVnszD5SmGUpKvBHR7YFES7r =AILx -END PGP SIGNATURE- -- 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] FWD: Re: Updated backslash consistency patch
Bruce Momjian escribió: > In thinking last night, I am now wondering if a letter is really the > right symbol for this. We already have letter flags which control > object type selection, but the system table addition is kind of > independent of those flags, like '+' now. I am thinking maybe '&' is > the right symbol rather than 'A' or 'S'. & is probably going to be useful as a modifier when we have concurrent psql, so I suggest you do not use it here. Or maybe not, but in any case see http://archives.postgresql.org/message-id/8204.1207689056%40sss.pgh.pa.us before you use &. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] FWD: Re: Updated backslash consistency patch
Robert Haas wrote: > > Here is what I hope is a consensus patch. It adds 'A' to show all > > objects, including system ones. It turns out that this is how 'S' works > > now in CVS, but 'S' is unclear because it suggests just system objects; > > 'A' for show 'all' objects seems clearer. > > I think it's probably fine for "S" to mean "include system objects" > rather than "show only system objects". Everyone should be relatively > used to "S" by now; I think it's less confusing to keep the same > letter even if the behavior has been adjusted somewhat. Though others > may disagree? OK, so you are saying you like the behavior in current CVS, which uses 'S' as you described. In thinking last night, I am now wondering if a letter is really the right symbol for this. We already have letter flags which control object type selection, but the system table addition is kind of independent of those flags, like '+' now. I am thinking maybe '&' is the right symbol rather than 'A' or 'S'. \df and \df& '&' would stand for "and system objects". We could use '*' but that might be confused with a wildcard symbol. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] FWD: Re: Updated backslash consistency patch
> Here is what I hope is a consensus patch. It adds 'A' to show all > objects, including system ones. It turns out that this is how 'S' works > now in CVS, but 'S' is unclear because it suggests just system objects; > 'A' for show 'all' objects seems clearer. I think it's probably fine for "S" to mean "include system objects" rather than "show only system objects". Everyone should be relatively used to "S" by now; I think it's less confusing to keep the same letter even if the behavior has been adjusted somewhat. Though others may disagree? (Although this met with some earlier opposition, mostly from Tom IIRC, I still think it might be useful to have a setting to control which types of system objects are displayed by default: the setting could be interpreted as a list of characters X for which \dX would include system objects even without S. This would allow people who liked the old behavior to mostly recreate it.) ...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] FWD: Re: Updated backslash consistency patch
Bruce Momjian wrote: > I know we don't like the current behavior, but I think we need to make > them consistent first for easy testing and so when we change it, it will > remain consistent. > > I will work on a consensus patch soon for the new behavior. Here is what I hope is a consensus patch. It adds 'A' to show all objects, including system ones. It turns out that this is how 'S' works now in CVS, but 'S' is unclear because it suggests just system objects; 'A' for show 'all' objects seems clearer. I did not add any special handling for patterns: test=> \df repeat List of functions Schema | Name | Result data type | Argument data types +--+--+- (0 rows) test=> \dfA repeat List of functions Schema | Name | Result data type | Argument data types ++--+- pg_catalog | repeat | text | text, integer (1 row) I am afraid that special pattern rules are going to be too confusing. You can see only system objects by referencing pg_catalog: test=> \dtA pg_catalog.pg_t* List of relations Schema | Name | Type | Owner +--+---+-- pg_catalog | pg_tablespace| table | postgres pg_catalog | pg_trigger | table | postgres pg_catalog | pg_ts_config | table | postgres pg_catalog | pg_ts_config_map | table | postgres pg_catalog | pg_ts_dict | table | postgres pg_catalog | pg_ts_parser | table | postgres pg_catalog | pg_ts_template | table | postgres pg_catalog | pg_type | table | postgres (8 rows) Patch attached. One interesting idea would be to assume 'A' if the a schema is specified in the pattern, so; \df pg_catalog.* would work without 'A'. With this patch, \d and \dt show only user tables, and \df shows only user functions. I think usability-wise, these are good, and \dA, \dtA, and \dfA include system tables and functions. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.218 diff -c -c -r1.218 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 20 Jan 2009 02:38:37 - 1.218 --- doc/src/sgml/ref/psql-ref.sgml 20 Jan 2009 03:54:20 - *** *** 833,840 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 letter S adds the listing of system ! objects; without S, only non-system objects are shown. --- 833,840 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 letter A adds the listing of system ! objects; without A, only non-system objects are shown. *** *** 859,866 return type and the data types they operate on. If pattern is specified, only aggregates whose names match the pattern are shown. ! The letter S adds the listing of system ! objects; without S, only non-system objects are shown. --- 859,866 return type and the data types they operate on. If pattern is specified, only aggregates whose names match the pattern are shown. ! The letter A adds the listing of system ! objects; without A, only non-system objects are shown. *** *** 890,897 If pattern is specified, only conversions whose names match the pattern are listed. ! The letter S adds the listing of system ! objects; without S, only non-system objects are shown. --- 890,897 If pattern is specified, only conversions whose names match the pattern are listed. ! The letter A adds the listing of system ! objects; without A, only non-system objects are shown. *** *** 919,926 class="parameter">pattern, or of all visible objects if no argument is given. But in either case, only objects that have a description are listed. ! The letter S adds the listing of system ! objects; without S, only non-system objects are shown. (O
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
Gregory Stark wrote:
> The behaviour of \dt in the face of tables which shadow system tables is
> actually even stranger:
>
> postgres=# create table pg_proc (t text);
> CREATE TABLE
> postgres=# commit;
> COMMIT
> postgres=# \dt pg_proc
> No matching relations found.
>
>
> And I don't see any reason aggregates, operators, etc, shouldn't be any more
> susceptible the shadowing problem.
The inconsistency between \d and \dt is not defensible, and no one said
they liked it. Here is an example:
test=> \d pg_language
--> Table "pg_catalog.pg_language"
Column | Type| Modifiers
---+---+---
lanname | name | not null
lanowner | oid | not null
lanispl | boolean | not null
lanpltrusted | boolean | not null
lanplcallfoid | oid | not null
lanvalidator | oid | not null
lanacl| aclitem[] |
Indexes:
"pg_language_name_index" UNIQUE, btree (lanname)
"pg_language_oid_index" UNIQUE, btree (oid)
test=> \dt pg_language
--> No matching relations found.
As you can see, \d shows system tables, while \dt does not. The
attached patch makes \d and \dt consistent:
test=> \d pg_language
Did not find any relation named "pg_language".
test=> \dt pg_language
No matching relations found.
test=> \dS pg_language
Table "pg_catalog.pg_language"
Column | Type| Modifiers
---+---+---
lanname | name | not null
lanowner | oid | not null
lanispl | boolean | not null
lanpltrusted | boolean | not null
lanplcallfoid | oid | not null
lanvalidator | oid | not null
lanacl| aclitem[] |
Indexes:
"pg_language_name_index" UNIQUE, btree (lanname)
"pg_language_oid_index" UNIQUE, btree (oid)
test=> \dtS pg_language
List of relations
Schema |Name | Type | Owner
+-+---+--
pg_catalog | pg_language | table | postgres
(1 row)
In pre-8.4, 'S' was recognised only by \dt.
The other part of the patch shows system and _user_ tables when \dtS is
used, to be consistent with the rest of the \d* commands.
I know we don't like the current behavior, but I think we need to make
them consistent first for easy testing and so when we change it, it will
remain consistent.
Applied. I will work on a consensus patch soon for the new behavior.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.201
diff -c -c -r1.201 command.c
*** src/bin/psql/command.c 6 Jan 2009 21:10:30 - 1.201
--- src/bin/psql/command.c 20 Jan 2009 02:02:17 -
***
*** 334,347
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
! show_system = strchr(cmd, 'S') ? true: false;
switch (cmd[1])
{
case '\0':
case '+':
if (pattern)
! success = describeTableDetails(pattern, show_verbose);
else
/* standard listing of interesting things */
success = listTables("tvs", NULL, show_verbose, show_system);
--- 334,348
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
! show_system = strchr(cmd, 'S') ? true : false;
switch (cmd[1])
{
case '\0':
case '+':
+ case 'S':
if (pattern)
! success = describeTableDetails(pattern, show_verbose, show_system);
else
/* standard listing of interesting things */
success = listTables("tvs", NULL, show_verbose, show_system);
***
*** 390,396
case 'v':
case 'i':
case 's':
- case 'S':
success = listTables(&cmd[1], pattern, show_verbose, show_system);
break;
case 'u':
--- 391,396
Index: src/bin/psql/describe.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.196
diff -c -c -r1.196 describe.c
*** src/bin/psql/describe.c 19 Jan 2009 18:44:32 - 1.196
--- src/bin/psql/describe.c 20 Jan 2009 02:02:17 -
***
*** 782,788
* verbose: if true, this is \d+
*/
bool
! describeTableDetails(const char *pattern, bool verbose)
{
PQExpBufferData buf;
PGresult *res;
--- 782,788
* verbose: if true, this is \d+
*/
bool
! describeTableDetails(const char *p
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
On Fri, Jan 16, 2009 at 3:16 PM, Tom Lane wrote: > Robert Haas writes: >> I can't shake the feeling that this is about a couple >> of PostgreSQL hackers (yourself included) not wanting to type \dfS or >> \dfA or something to get the behavior they currently get with \df. If >> that's the case, come off it, because there's lots of evidence on this >> thread (and in all likelihood elsewhere) that this behavior is not >> what end-users want. > > As was made clear at the beginning of the thread, that's what they > *think* they want, without any experience with a system that actually > behaves that way. And yes I do believe I know better, both from knowing > how the system works and from actual experience with the ill-considered > patch that's now in HEAD. I'm willing to provide a "U" modifier but > I think it will be a serious error to make that the default behavior. 1. Providing the U modifier is a step in the right direction. 2. I agree that developers sometimes know better than users what users actually want. I have a pretty good track record there myself. 3. On this thread, we have you, Peter Eisentraut, and Heikki Linnakangas arguing for reverting the default behavior of \df, and we have (by my tally, apologies to anyone I've missed or misrepresented) Greg Sabino Mullane, Josh Berkus, Josh Drake, Greg Stark, David Fetter, Dmitri Fontaine, Stephen Frost, and myself expressing support for the change (with various differences of opinion on what other alternatives might not or might not be better). So in this case I think you don't know better. However, by my count, zero of the people who like the change are committers and all of the people who don't like it are, so we may be out of luck. :-) ...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] FWD: Re: Updated backslash consistency patch
Robert Haas writes: > I can't shake the feeling that this is about a couple > of PostgreSQL hackers (yourself included) not wanting to type \dfS or > \dfA or something to get the behavior they currently get with \df. If > that's the case, come off it, because there's lots of evidence on this > thread (and in all likelihood elsewhere) that this behavior is not > what end-users want. As was made clear at the beginning of the thread, that's what they *think* they want, without any experience with a system that actually behaves that way. And yes I do believe I know better, both from knowing how the system works and from actual experience with the ill-considered patch that's now in HEAD. I'm willing to provide a "U" modifier but I think it will be a serious error to make that the default behavior. 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] FWD: Re: Updated backslash consistency patch
"Kevin Grittner" writes: > Is the bare form (no U or S) going to search all schemas or the ones > on the search path? Whatever the answer, do we need a way to get the > other? The former, if you specify "*.*" (or "*.anything") as your pattern. The latter, if you don't specify a schema qualifier in your pattern. This already works and has since 7.3; I don't think we need to embed any such semantics in the command names. 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] FWD: Re: Updated backslash consistency patch
Robert Haas writes: > I think you should make: > \df - non-system only > \dfS - system only > \dfA - all > Then you could make \dt the same way, and it wouldn't involve breaking > the way \dt works now. No, instead it would break \df. As I said before, a solution that was designed for tables back around 6.4 isn't good enough for functions in a schema world. 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] FWD: Re: Updated backslash consistency patch
> Actually, now that I look at the code, the historical behavior of > \d is even weirder than I thought: > >\d or \d+ *with no pattern* is equivalent to \dtvs(+) >(and hence shows all user tables and no system tables) > >\d or \d+ *with a pattern* takes a completely different >code path that has no system-vs-user special behavior, >ie it's about like the historical \df behavior > > which means that Robert's complaint about treating no-pattern > differently from pattern falls to the ground. It's exactly what > \d has done for years, and nobody has complained about that. Well, the behavior of \d with a pattern is almost totally useless right now. Probably no one is doing "\d a*" because it produces an obscene amount of output (or if you don't have more than one table with a, then pick some other letter). On the other hand "\dt a*" does something very nice that is just what you might expect. But you're right: my facts were wrong with respect to treating no-pattern differently than pattern. I don't think that makes the point invalid. I can't shake the feeling that this is about a couple of PostgreSQL hackers (yourself included) not wanting to type \dfS or \dfA or something to get the behavior they currently get with \df. If that's the case, come off it, because there's lots of evidence on this thread (and in all likelihood elsewhere) that this behavior is not what end-users want. Making \df only show user functions, and "\df " only search user functions, is going to make a LOT of people happy (perhaps after 5 minutes of initial confusion). If it makes three developers unhappy, it's worth it - especially because the developers can easily add a switch, backslash command, environment variable setting, or whatever they want to still be able to have it the way they like it. By all means, add a setting that includes system stuff without having to type an extra letter - just don't make it the default. ...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] FWD: Re: Updated backslash consistency patch
Josh Berkus writes: > Tom, >> which means that Robert's complaint about treating no-pattern >> differently from pattern falls to the ground. It's exactly what >> \d has done for years, and nobody has complained about that. > Just because they haven't voiced loud complaints doesn't mean that they > haven't been *confused* by it. I know that I've been confused by the > behaviour of \d before, which is why I pretty much never use it. > I think a search of -general and -newbie would be educational on the > number of people who are confused by the shortcuts. > Or, to put it another way, the fact that we screwed up in the past is > hardly a justification to do it in the future. Well, the only reason for proposing the special case for no-pattern was to provide some modicum of backward compatibility for \d and \dt. If we want to decide that those are screwed up anyway and we should make them work more like the other ones, that'd be okay with me. But I have gotten the clear impression that such a proposal isn't going to get majority support. I think though that your confusion may come from an aspect of \d's behavior that is more or less orthogonal to what we've been discussing: without a pattern it equates to \dtvs, that is you get a summary one-line-per-relation display of tables, views, and sequences; whereas with a pattern it does something entirely different, to wit you get a verbose display about each matching relation. Maybe we should reconsider that bit; but it's a different argument from the one about system vs user objects. [ thinks a bit... ] One interesting idea is to go with the all/S/U behavior for \dt, but to define bare "\d" as meaning "\dtvsU" not just "\dtvs". That keeps backwards compatibility for that specific case without introducing any conceptual inconsistency into the rest of the command set. 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] FWD: Re: Updated backslash consistency patch
On Fri, Jan 16, 2009 at 1:37 PM, Tom Lane wrote: > Robert Haas writes: >> I feel pretty strongly that making the pattern search against a >> different list of stuff than what the same command would display >> without the pattern is confusing and a bad idea. It's a bad idea >> regardless of which particular backslash-sequence we're talking about. > > Well, I'm perfectly happy to drop that stipulation and just go with > >\df -- all >\dfS-- system only >\dfU-- non-system only > > but are we willing to change \d and \dt to work that way too? > Or should we leave them inconsistent? I think you should make: \df - non-system only \dfS - system only \dfA - all Then you could make \dt the same way, and it wouldn't involve breaking the way \dt works now. ...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] FWD: Re: Updated backslash consistency patch
Tom, which means that Robert's complaint about treating no-pattern differently from pattern falls to the ground. It's exactly what \d has done for years, and nobody has complained about that. Just because they haven't voiced loud complaints doesn't mean that they haven't been *confused* by it. I know that I've been confused by the behaviour of \d before, which is why I pretty much never use it. I think a search of -general and -newbie would be educational on the number of people who are confused by the shortcuts. Or, to put it another way, the fact that we screwed up in the past is hardly a justification to do it in the future. --Josh -- 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] FWD: Re: Updated backslash consistency patch
"Greg Sabino Mullane" writes: >> I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close >> approximation to that. The behavior you are asking for is essentially >> "I want to pay attention to the search path, except not actually follow >> its rules", which is bogus. Either you want to see the functions you >> can call without schema qualification, or you want to see 'em all --- >> it does no good whatsoever to lie about the visibility. > But that's what \dt and \di and \dv have done since forever, and I've > never heard a single complaint about it. The reason it's not really an issue for those is that we still maintain the convention that system catalogs have names beginning with "pg_", and most people still avoid such names for user tables, and so there is no conflict that search path order would matter for. With function names there is no such standard and thus far greater risk of collisions. It is a serious, serious error to suppose that behavior that is good enough for tables (and in fact was designed before we had schemas...) is also good enough for functions. 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] FWD: Re: Updated backslash consistency patch
"David E. Wheeler" writes: > On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote: >>> but are we willing to change \d and \dt to work that way too? >>> Or should we leave them inconsistent? >> >> I would prefer them consistent. > I think that people will hate the changed behavior to \d and \dt. Yeah, one of the advantages of the simpler proposal is that the behavior of plain \df doesn't change from what it was, so there's no surprise factor, just a couple of new options. But if we apply that same behavior to \d and \dt then we do have a change in default behavior. The point of "assume U for no pattern" was to preserve the default behavior of those two commands. Actually, now that I look at the code, the historical behavior of \d is even weirder than I thought: \d or \d+ *with no pattern* is equivalent to \dtvs(+) (and hence shows all user tables and no system tables) \d or \d+ *with a pattern* takes a completely different code path that has no system-vs-user special behavior, ie it's about like the historical \df behavior which means that Robert's complaint about treating no-pattern differently from pattern falls to the ground. It's exactly what \d has done for years, and nobody has complained about that. 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] FWD: Re: Updated backslash consistency patch
>>> Tom Lane wrote: > Comments? Does this cover all the cases? I tend to think that changing which schemas are searched based on the presence or absence of a search pattern is a bad idea. Is the bare form (no U or S) going to search all schemas or the ones on the search path? Whatever the answer, do we need a way to get the other? +1 for consistency across all \d commands, even though I almost always want to see just the user objects. IMO it's worth the extra keystroke to be sure of what I'm seeing. -Kevin -- 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] FWD: Re: Updated backslash consistency patch
On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote: \df -- all \dfS-- system only \dfU-- non-system only but are we willing to change \d and \dt to work that way too? Or should we leave them inconsistent? I would prefer them consistent. I think that people will hate the changed behavior to \d and \dt. Best, David -- 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] FWD: Re: Updated backslash consistency patch
Tom Lane wrote: Robert Haas writes: I feel pretty strongly that making the pattern search against a different list of stuff than what the same command would display without the pattern is confusing and a bad idea. It's a bad idea regardless of which particular backslash-sequence we're talking about. Well, I'm perfectly happy to drop that stipulation and just go with \df -- all \dfS-- system only \dfU-- non-system only but are we willing to change \d and \dt to work that way too? Or should we leave them inconsistent? I think changing \dt would confuse the heck out of people. Far more than changing \df to be consistent with \dt would be. So my votes, in order of preference, are: 1) make \df consistent with \dt 2) leave them inconsistent --Josh -- 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] FWD: Re: Updated backslash consistency patch
On Fri, 2009-01-16 at 13:37 -0500, Tom Lane wrote: > Robert Haas writes: > > I feel pretty strongly that making the pattern search against a > > different list of stuff than what the same command would display > > without the pattern is confusing and a bad idea. It's a bad idea > > regardless of which particular backslash-sequence we're talking about. > > Well, I'm perfectly happy to drop that stipulation and just go with > > \df -- all > \dfS-- system only > \dfU-- non-system only > > but are we willing to change \d and \dt to work that way too? > Or should we leave them inconsistent? > I would prefer them consistent. Joshua D. Drake > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] FWD: Re: Updated backslash consistency patch
Robert Haas writes: > I feel pretty strongly that making the pattern search against a > different list of stuff than what the same command would display > without the pattern is confusing and a bad idea. It's a bad idea > regardless of which particular backslash-sequence we're talking about. Well, I'm perfectly happy to drop that stipulation and just go with \df -- all \dfS-- system only \dfU-- non-system only but are we willing to change \d and \dt to work that way too? Or should we leave them inconsistent? 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] FWD: Re: Updated backslash consistency patch
On Fri, Jan 16, 2009 at 1:09 PM, Tom Lane wrote: > Robert Haas writes: >> Changing the scope of the search on the basis of whether or not a >> pattern is present strikes me as a terrible idea. It's confusing and >> unlikely to make anyone happy. > > Huh? The pattern itself "changes the scope of the search", so I don't > see how this is a conceptual violation. > > Not that I'd personally be unhappy with dropping that part of the > proposal, but this doesn't seem like a good argument against it. I don't understand your confusion. You're once again proposing to have \df display only user functions, and \df search both user and system functions. That doesn't seem remotely sane to me. Now I do "\df"and get a list of 30 functions, and that's more than I want to wade through so I do "\df a*" and get a list of 60 functions. Yuck! I feel pretty strongly that making the pattern search against a different list of stuff than what the same command would display without the pattern is confusing and a bad idea. It's a bad idea regardless of which particular backslash-sequence we're talking about. It doesn't work that way in 8.3.x, it doesn't work that way in CVS HEAD, and it seems quite obvious it will confuse and annoy end-users. ...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] FWD: Re: Updated backslash consistency patch
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close > approximation to that. The behavior you are asking for is essentially > "I want to pay attention to the search path, except not actually follow > its rules", which is bogus. Either you want to see the functions you > can call without schema qualification, or you want to see 'em all --- > it does no good whatsoever to lie about the visibility. But that's what \dt and \di and \dv have done since forever, and I've never heard a single complaint about it. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200901161321 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAklw0MwACgkQvJuQZxSWSsj5LQCeIl2j+/fT2v0G6aZ/0UnRcCVl xUoAnj1OBE8mPL9qJHxo+ETwWSHrfFJj =vtEm -END PGP SIGNATURE- -- 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] FWD: Re: Updated backslash consistency patch
Robert Haas writes: > Changing the scope of the search on the basis of whether or not a > pattern is present strikes me as a terrible idea. It's confusing and > unlikely to make anyone happy. Huh? The pattern itself "changes the scope of the search", so I don't see how this is a conceptual violation. Not that I'd personally be unhappy with dropping that part of the proposal, but this doesn't seem like a good argument against it. 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] FWD: Re: Updated backslash consistency patch
> One issue here is that plain \d gets less useful because it'll now > include system catalogs. We could add the additional rule that > the above statements apply only when a pattern is specified, and > without a pattern you get just user stuff (so omitting a pattern > corresponds to pattern "*" with the U modifier, not just "*"). > This would probably make it a bit easier to have exactly the same > rules across the board. Changing the scope of the search on the basis of whether or not a pattern is present strikes me as a terrible idea. It's confusing and unlikely to make anyone happy. ...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] FWD: Re: Updated backslash consistency patch
"Greg Sabino Mullane" writes: >> Comments? Does this cover all the cases? > No: the user case someone had upthread, where they want to see all their > functions starting with an "a" across all schemas in their path: > \df a* I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close approximation to that. The behavior you are asking for is essentially "I want to pay attention to the search path, except not actually follow its rules", which is bogus. Either you want to see the functions you can call without schema qualification, or you want to see 'em all --- it does no good whatsoever to lie about the visibility. 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] FWD: Re: Updated backslash consistency patch
On Fri, 2009-01-16 at 12:40 -0500, Tom Lane wrote: > "Joshua D. Drake" writes: > >>> Again, "\dfS" would be a bit useless, unless we say that the implicit > >>> U modifier for no pattern doesn't override an explicit S modifier. > >>> > >>> Comments? Does this cover all the cases? > >> > >> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding > >> something? > > > \df would act as it does now. Showing you *everything*. > > Which part of the quoted paragraph didn't you read? Apparently at least part. Sorry for the noise. Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] FWD: Re: Updated backslash consistency patch
"Joshua D. Drake" writes: > On Fri, 2009-01-16 at 09:14 -0800, David E. Wheeler wrote: >> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote: >>> One issue here is that plain \d gets less useful because it'll now >>> include system catalogs. We could add the additional rule that >>> the above statements apply only when a pattern is specified, and >>> without a pattern you get just user stuff (so omitting a pattern >>> corresponds to pattern "*" with the U modifier, not just "*"). >>> This would probably make it a bit easier to have exactly the same >>> rules across the board. >>> >>> Again, "\dfS" would be a bit useless, unless we say that the implicit >>> U modifier for no pattern doesn't override an explicit S modifier. >>> >>> Comments? Does this cover all the cases? >> >> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding >> something? > \df would act as it does now. Showing you *everything*. Which part of the quoted paragraph didn't you read? 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] FWD: Re: Updated backslash consistency patch
On Jan 16, 2009, at 9:35 AM, Tom Lane wrote: So would "\df" then be equivalent to "\dU"? Or am I misunderstanding something? You mean "\dfU"? Yes, if there's no pattern. Yeah, that's what I meant. Thanks. +1. Best, David -- 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] FWD: Re: Updated backslash consistency patch
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> One issue here is that plain \d gets less useful because it'll now
> include system catalogs.
Are you kidding me? No way. That's a recipe for making all our users
unhappy with us.
> * \dfU will restrict the printout to non-system functions
Sorry, but the "U" is ugly and unnecessary. The *default* should always
be user-defined functions, and to hide the internals. Hence, we have a
special flag for when you know what you are doing and want to see the system
information: "S".
I do agree that \d is not consistent with anything else, but let's not
throw the baby out with the bathwater. Or if we do, let's not have \d
show sequences either, because that part always annoyed me. :)
> Comments? Does this cover all the cases?
No: the user case someone had upthread, where they want to see all their
functions starting with an "a" across all schemas in their path:
\df a*
This should act similar to how \dt does right now:
\dt p*
Such that it shows only the user's functions, and only the user's tables.
99% of the time, people don't care about or want to see the 60+ internal
functions starting with "a", and the 40 or so internal tables
starting with "p".
I'm willing to concede some of the "\d.{1} objectname" behavior, but I don't
think we should mess at all with "\d" or "\dt" because people are used
to the current behavior, and its rather sane and useful (unlike \df)
- --
Greg Sabino Mullane g...@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200901161234
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-
iEYEAREDAAYFAklwxXgACgkQvJuQZxSWSsgawACeMox6/RveSyvRJ4gpe/TiLSR3
YeYAoOBxy6IpTLdHYI40haMAgCebobLB
=Dj3a
-END PGP SIGNATURE-
--
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] FWD: Re: Updated backslash consistency patch
"David E. Wheeler" writes: > On Jan 16, 2009, at 8:36 AM, Tom Lane wrote: >> Comments? Does this cover all the cases? > So would "\df" then be equivalent to "\dU"? Or am I misunderstanding > something? You mean "\dfU"? Yes, if there's no pattern. 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] FWD: Re: Updated backslash consistency patch
On Fri, 2009-01-16 at 09:14 -0800, David E. Wheeler wrote: > On Jan 16, 2009, at 8:36 AM, Tom Lane wrote: > > > One issue here is that plain \d gets less useful because it'll now > > include system catalogs. We could add the additional rule that > > the above statements apply only when a pattern is specified, and > > without a pattern you get just user stuff (so omitting a pattern > > corresponds to pattern "*" with the U modifier, not just "*"). > > This would probably make it a bit easier to have exactly the same > > rules across the board. > > > > Again, "\dfS" would be a bit useless, unless we say that the implicit > > U modifier for no pattern doesn't override an explicit S modifier. > > > > Comments? Does this cover all the cases? > > So would "\df" then be equivalent to "\dU"? Or am I misunderstanding > something? \df would act as it does now. Showing you *everything*. Joshua D. Drake > > David > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] FWD: Re: Updated backslash consistency patch
On Jan 16, 2009, at 8:36 AM, Tom Lane wrote: One issue here is that plain \d gets less useful because it'll now include system catalogs. We could add the additional rule that the above statements apply only when a pattern is specified, and without a pattern you get just user stuff (so omitting a pattern corresponds to pattern "*" with the U modifier, not just "*"). This would probably make it a bit easier to have exactly the same rules across the board. Again, "\dfS" would be a bit useless, unless we say that the implicit U modifier for no pattern doesn't override an explicit S modifier. Comments? Does this cover all the cases? So would "\df" then be equivalent to "\dU"? Or am I misunderstanding something? David -- 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] FWD: Re: Updated backslash consistency patch
Gregory Stark writes: > So it seems to me that we made \df consistent with \dt when in fact what we > really wanted is for it to be consistent with \d. I hadn't actually realized > that the behaviour for \d was so different from \dt myself. Yeah, given that the battle cry for this patch was "let's make everything consistent", it seems like some attention should be paid to that. I think that when everybody got tired of arguing yesterday, the last idea left standing was * revert \df to its former behavior, ie doesn't care if functions are system or user * \dfS will restrict the printout to system functions * \dfU will restrict the printout to non-system functions where "system function" means "it's in the pg_catalog schema". (Presumably this means that "\dfS public.*" fails to print anything ... is that okay?) I suggest that we make all the \d commands work like that, including \d and \dt. One issue here is that plain \d gets less useful because it'll now include system catalogs. We could add the additional rule that the above statements apply only when a pattern is specified, and without a pattern you get just user stuff (so omitting a pattern corresponds to pattern "*" with the U modifier, not just "*"). This would probably make it a bit easier to have exactly the same rules across the board. Again, "\dfS" would be a bit useless, unless we say that the implicit U modifier for no pattern doesn't override an explicit S modifier. Comments? Does this cover all the cases? 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] FWD: Re: Updated backslash consistency patch
Tom Lane writes: > Well, as I said before, I'm not averse to having the default behavior > *with no pattern* to be that we omit system objects --- and I think we > could make that apply across the board. What I'm saying is that when > you give a pattern it should not matter whether an object is system or > user. It would go like this: > > \df -- all non-system functions > \df sin -- the active (visible) definition of sin() > \df sin* -- all visible functions starting with "sin" > > lesser used cases: > > \df * -- all visible functions > \df *.* -- all functions, period > \df pg_catalog.* -- all system functions > \df public.* -- all functions in public So it seems to me that we made \df consistent with \dt when in fact what we really wanted is for it to be consistent with \d. I hadn't actually realized that the behaviour for \d was so different from \dt myself. The behaviour of \dt in the face of tables which shadow system tables is actually even stranger: postgres=# create table pg_proc (t text); CREATE TABLE postgres=# commit; COMMIT postgres=# \dt pg_proc No matching relations found. And I don't see any reason aggregates, operators, etc, shouldn't be any more susceptible the shadowing problem. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
