Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen Frost wrote: -- Start of PGP signed section. > Bruce, et al, > > * Bruce Momjian (br...@momjian.us) wrote: > > \dg [PATTERN]list roles (groups) > > \du [PATTERN]list roles (users) > > Seeing this list reminded me of a pet-peeve.. \du and \dg actually show > the same info, that's fine, but neither of them show the rolcanlogin > value. As someone who has a bad habit of doing 'create role blah;' for > new users this can get very annoying. I also have people complain to me > that they can't figure out why a new user can't log in after they did > the same thing. Could we get that changed? Or maybe have 'connections' > say something different when you don't have rolcanlogin besides 'no > limit'? \du/\dg shows the "Cannot login" specification, which I think is sufficient. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen Frost writes: > Seeing this list reminded me of a pet-peeve.. \du and \dg actually show > the same info, that's fine, but neither of them show the rolcanlogin > value. +1 for fixing that. >> \dp [PATTERN]list table, view, and sequence access privileges > erp, I don't think I changed this in my column-level privleges patch.. > Should we explicitly mention column in this list? No, I think it's good as-is. Adding column here would suggest that columns are handled exactly parallel to tables, views, or sequences, which of course isn't the case. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce, et al, * Bruce Momjian (br...@momjian.us) wrote: > \dg [PATTERN]list roles (groups) > \du [PATTERN]list roles (users) Seeing this list reminded me of a pet-peeve.. \du and \dg actually show the same info, that's fine, but neither of them show the rolcanlogin value. As someone who has a bad habit of doing 'create role blah;' for new users this can get very annoying. I also have people complain to me that they can't figure out why a new user can't log in after they did the same thing. Could we get that changed? Or maybe have 'connections' say something different when you don't have rolcanlogin besides 'no limit'? > \dp [PATTERN]list table, view, and sequence access privileges erp, I don't think I changed this in my column-level privleges patch.. Should we explicitly mention column in this list? Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
* Robert Haas (robertmh...@gmail.com) wrote: > > Here are the items I think are best to default to user-only: > [...] > > Here are the ones that should include system objects by default: [...] > So maybe we should provide U, S, and A modifiers for every type of > object (user, system, all). That doesn't solve the problem of which > should be the default for each object type, but at least it guarantees > that you can type an extra character to get the behavior you want in > any particular case. You know, there's an easy answer to what to set the defaults to, though it might be a bit cheesy- how about the current behavior? Adding functionality (+U or +S or whatever) without breaking backwards compatibility (much). I'm not a huge fan of having \df still list system functions, but it's less of an issue if I can just do \dfU when I want. Of course, for a year or two I'll probably be cursing this thread whenver I pick the wrong one, but that's life. ;) In response to a comment earlier- I definitely like the idea of pre-pending system calls that aren't really 'published' with a 'pg_'. That probably raises some backwords compatability problems, but I still think it's a good idea to try and do at some point. Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
> Here are the items I think are best to default to user-only: [...] > Here are the ones that should include system objects by default: Well, at a minimum, I think it's important for any type of object to have an easy way to exclude system objects, because "show me all of the stuff that didn't come with the database" is a valid use case for any type of item. It's certainly true that the more obscure the item is, the more likely you are to be looking for the system object rather than a user object. But it's really subjective where to put the line: some people might put it between table and function (Tom), others might put it between function and aggregate (Bruce), and still others might say there's no object type so exotic that I don't want system objects excluded by default (me). And there isn't any right or wrong answer here: it's just opinions. So maybe we should provide U, S, and A modifiers for every type of object (user, system, all). That doesn't solve the problem of which should be the default for each object type, but at least it guarantees that you can type an extra character to get the behavior you want in any particular case. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > Alvaro Herrera wrote: > > > Bruce Momjian escribi?: > > > > > > > Well, to do this you are going to need 'U' and 'S' modifiers, and then > > > > we have to decide how \df is supposed to behave. > > > > > > I think we should have first decided how it was supposed to behave, and > > > later applied any patches. > > > > Well, there was a lot of discussion in the Spring that the backslash > > commands should be consistent, > > Yeah, apparently the idea that consistency is not necessarily the best > guiding principle did not emerge until after the patch was applied :-( You are seeing that too? ;-) We certainly needed to get this into CVS so folks could test it, and \d,\dt was so mangled in their behavior that only fixing it in CVS allowed people to see a clear picture. Here is the list we care about, from CVS HEAD: Informational Modifiers: S = show system objects + = Additional detail \l[+] list all databases \d[S+]list tables, views, and sequences \d[S+] NAME describe table, view, sequence, or index \da[S] [PATTERN]list aggregate functions \db[+] [PATTERN]list tablespaces \dc[S] [PATTERN]list conversions \dC [PATTERN]list casts \dd[S] [PATTERN]show comments on objects \dD[S] [PATTERN]list domains \des[+] [PATTERN]list foreign servers \deu[+] [PATTERN]list user mappings \dew[+] [PATTERN]list foreign-data wrappers \df[S+] [PATTERN]list functions \dF[+] [PATTERN]list text search configurations \dFd[+] [PATTERN]list text search dictionaries \dFp[+] [PATTERN]list text search parsers \dFt[+] [PATTERN]list text search templates \dg [PATTERN]list roles (groups) \di[S+] [PATTERN]list indexes \dl list large objects, same as \lo_list \dn[+] [PATTERN]list schemas \do[S] [PATTERN]list operators \dp [PATTERN]list table, view, and sequence access privileges \z [PATTERN]same as \dp \ds[S+] [PATTERN]list sequences \dt[S+] [PATTERN]list tables \dT[S+] [PATTERN]list data types \du [PATTERN]list roles (users) \dv[S+] [PATTERN]list views Here are the items I think are best to default to user-only: \d[S+]list tables, views, and sequences \d[S+] NAME describe table, view, sequence, or index \df[S+] [PATTERN]list functions \di[S+] [PATTERN]list indexes \ds[S+] [PATTERN]list sequences \dt[S+] [PATTERN]list tables \dv[S+] [PATTERN]list views \dD[S] [PATTERN]list domains Here are the ones that should include system objects by default: \da[S] [PATTERN]list aggregate functions \dc[S] [PATTERN]list conversions \dd[S] [PATTERN]show comments on objects \do[S] [PATTERN]list operators \dT[S+] [PATTERN]list data types The lists are pretty close to being the same size, especially since \d is listed twice. You will notice some commands, like \dF, are not listed at all because they don't support 'S'. One new idea would be to remove 'S' support from the "include system" group and have them default to showing system objects. We could add a 'U' flag but that introduces confusion over whether the command without 'S' or 'U' shows system objects, and would 'S' show only system objects, or include system objects? And what about 'U'? -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian escribió: > Alvaro Herrera wrote: > > Bruce Momjian escribi?: > > > > > Well, to do this you are going to need 'U' and 'S' modifiers, and then > > > we have to decide how \df is supposed to behave. > > > > I think we should have first decided how it was supposed to behave, and > > later applied any patches. > > Well, there was a lot of discussion in the Spring that the backslash > commands should be consistent, Yeah, apparently the idea that consistency is not necessarily the best guiding principle did not emerge until after the patch was applied :-( -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > > Well, to do this you are going to need 'U' and 'S' modifiers, and then > > we have to decide how \df is supposed to behave. > > I think we should have first decided how it was supposed to behave, and > later applied any patches. Well, there was a lot of discussion in the Spring that the backslash commands should be consistent, Greg Sabino Mullane went away to work on the patch, but didn't finish until my prodding in October, so I then applied it. \df seemed to be the hot item, and the rest just fell into place. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian escribió: > Well, to do this you are going to need 'U' and 'S' modifiers, and then > we have to decide how \df is supposed to behave. I think we should have first decided how it was supposed to behave, and later applied any patches. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > > But frankly, with a very complex backslash API that is already > > overloaded, I figured having a consistent 'S' to include system objects > > was the best we are going to be able to do. Once this is out in the > > field we might get new ideas. > > I don't buy this argument. If we're going to break backwards > compatibility we should only do so to get a better UI. Not because "we > might get new ideas". > > After all this discussion, I'm not sure I understand why is it so > important that all \ commands behave "consistently". Since psql is > primarily a user-convenience tool, it seems that it needs to be usable > first, consistent second. In most cases, usable means consistent (think > having the OK button at the same side of the Cancel button in all dialog > boxes), but this is one of the other cases, because the requirements for > some situations are clearly at odds in other situations (or as Peter > puts it: it is seldom useful to display pg_catalog tables, but it is > very often useful to display pg_catalog types). Well, to do this you are going to need 'U' and 'S' modifiers, and then we have to decide how \df is supposed to behave. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian escribió: > But frankly, with a very complex backslash API that is already > overloaded, I figured having a consistent 'S' to include system objects > was the best we are going to be able to do. Once this is out in the > field we might get new ideas. I don't buy this argument. If we're going to break backwards compatibility we should only do so to get a better UI. Not because "we might get new ideas". After all this discussion, I'm not sure I understand why is it so important that all \ commands behave "consistently". Since psql is primarily a user-convenience tool, it seems that it needs to be usable first, consistent second. In most cases, usable means consistent (think having the OK button at the same side of the Cancel button in all dialog boxes), but this is one of the other cases, because the requirements for some situations are clearly at odds in other situations (or as Peter puts it: it is seldom useful to display pg_catalog tables, but it is very often useful to display pg_catalog types). -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Peter Eisentraut wrote: > On Friday 16 January 2009 04:09:11 Robert Haas wrote: > > I really wonder what is so terrible about the behavrior as implemented > > in CVS HEAD. ?AFAICS, no one except maybe Tom has really specified WHY > > they don't like it, just that they don't like it. ?I'm not sure > > whether that's because (1) it's different, and they're used to the old > > way; (2) it involves typing an extra character to get the behavior > > they want; or (3) there's no way to search user and system functions > > simultaneously. > > Btw., the reason why I didn't like it is that hiding system tables is OK, > because you never really interact with them, but hiding system functions is > not, because you use those all the time. It has emerged, however, that some > people appear to think of \df in terms of "what's available" and some in > terms of "what have I done". And those call for different behaviors. Yep. I thought about what would be the ideal behavior of each backslash command that supports 'S'. Some \d commands are better with just user objects (\dt), while others are better including system objects (\dT), and some are unclear (\df). (You have to love that.) My feeling was to focus on the most used commands (\dt) and figure out how they would behave best, and let the others follow. Arguably the \dtisv are good in current CVS, while it is unclear if \df is better or worse than 8.3, and \dT is certainly worse than 8.3. But frankly, with a very complex backslash API that is already overloaded, I figured having a consistent 'S' to include system objects was the best we are going to be able to do. Once this is out in the field we might get new ideas. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Friday 16 January 2009 04:09:11 Robert Haas wrote: > I really wonder what is so terrible about the behavrior as implemented > in CVS HEAD. AFAICS, no one except maybe Tom has really specified WHY > they don't like it, just that they don't like it. I'm not sure > whether that's because (1) it's different, and they're used to the old > way; (2) it involves typing an extra character to get the behavior > they want; or (3) there's no way to search user and system functions > simultaneously. Btw., the reason why I didn't like it is that hiding system tables is OK, because you never really interact with them, but hiding system functions is not, because you use those all the time. It has emerged, however, that some people appear to think of \df in terms of "what's available" and some in terms of "what have I done". And those call for different behaviors. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvhe...@commandprompt.com) wrote: >> Tom Lane escribió: >>> If you have an idle evening you might want to peruse all the past >>> threads about developing better support for modules. >> All the useful material in this area is linked to on the TODO list. > > Thanks for the pointer. I think PostGIS makes a very good test case for > anything new we come up with, both in terms of trying to not break > things too badly for their existing users, and in being a pretty complex > module that's rather popular. Suggestions on others? Contrib modules.. Like pgcrypto for example. tsearch2 used to be a great example of this, until it was integrated. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, 2009-01-15 at 20:19 -0800, Josh Berkus wrote: > Tom, > > > Also (3) you are not actually going to use this as much as you think > > you are, so saving a shift keypress is not the be-all and end-all. > > Clearly you've never had to troubleshoot a client's database which has > over 400 functions they've never completely documented. I have and anyone who has come anywhere close to what we have knows this is useful on a significant level. Joshua D. Draek -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh Berkus wrote: Tom, Also (3) you are not actually going to use this as much as you think you are, so saving a shift keypress is not the be-all and end-all. Clearly you've never had to troubleshoot a client's database which has over 400 functions they've never completely documented. Oh ... he above was just a comment, and NOT an argument for different syntax. Please let's end the discussion of this very small feature, and move on to things that deserve it, like SELinux and Hot standby? --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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom, Also (3) you are not actually going to use this as much as you think you are, so saving a shift keypress is not the be-all and end-all. Clearly you've never had to troubleshoot a client's database which has over 400 functions they've never completely documented. --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: FWD: Re: [HACKERS] Updated backslash consistency patch
Alvaro, * Alvaro Herrera (alvhe...@commandprompt.com) wrote: > Tom Lane escribió: > > If you have an idle evening you might want to peruse all the past > > threads about developing better support for modules. > > All the useful material in this area is linked to on the TODO list. Thanks for the pointer. I think PostGIS makes a very good test case for anything new we come up with, both in terms of trying to not break things too badly for their existing users, and in being a pretty complex module that's rather popular. Suggestions on others? Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
* Tom Lane (t...@sss.pgh.pa.us) wrote: > If you have an idle evening you might want to peruse all the past > threads about developing better support for modules. This is clearly > an area where we need to improve, and it's also clear that no quick > hack is going to make it significantly better (in fact, it might make > things worse by creating extra compatibility issues when we do get > around to implementing a real solution). I'll try and do that over the next few weeks, I recall seeing at least some of those threads. Perhaps we can come up with a good approach to improve module support for 8.5. > The main argument against sticking stuff into pg_catalog is that > pg_dump will think it's a built-in and not dump it. In some respects > that could be a plus, but for the most part it's a headache. Yeah, that issue did occur to me, though my plan for Debian on upgrades was to try and filter out the PostGIS functions from the old database and cleanly install them in the new database from scratch, which would be more easily done if they're just not included in the old dump. On the flip side, the support tables for PostGIS need to be migrated, so something special would have to be done there if they were in pg_catalog. Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom Lane escribió: > Stephen Frost writes: > > As I mentioned in my other email, this is mainly for PostGIS, but it can > > certainly apply to other modules. Is this what we would recommend as an > > approach for these kinds of modules? I feel like that would give > > -hackers, or perhaps the PostGIS people, some heartburn, but maybe I'm > > wrong? > > If you have an idle evening you might want to peruse all the past > threads about developing better support for modules. All the useful material in this area is linked to on the TODO list. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen Frost writes: > As I mentioned in my other email, this is mainly for PostGIS, but it can > certainly apply to other modules. Is this what we would recommend as an > approach for these kinds of modules? I feel like that would give > -hackers, or perhaps the PostGIS people, some heartburn, but maybe I'm > wrong? If you have an idle evening you might want to peruse all the past threads about developing better support for modules. This is clearly an area where we need to improve, and it's also clear that no quick hack is going to make it significantly better (in fact, it might make things worse by creating extra compatibility issues when we do get around to implementing a real solution). The main argument against sticking stuff into pg_catalog is that pg_dump will think it's a built-in and not dump it. In some respects that could be a plus, but for the most part it's a headache. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Read the documentation for search_path: if pg_catalog isn't explicitly > mentioned, we add it implicitly. This is mainly because it would be > contrary to SQL spec (and pretty useless to boot) to not recognize the > standard functions and operators. But beyond that hack, there is no > mechanism other than search_path that determines what's visible or not. Sorry, I didn't mean to imply I was completely oblivious to this. I think I spoke a little too quickly and phrased it poorly. It would be nice for an administrator to be able to implicitly add other schemas to the search_path, primairly for functions but possibly other things, because that way add-on modules like PostGIS could look more like they're just part of PG. Another option might be to add things to pg_catalog, but I suspect that's frowned upon with good reason. Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen Frost writes: > Regardless of what I reset my search_path to, I'm going to have access > to abstime. Is there something else special about it besides being > a 'system function' and being in pg_catalog to make it always available > regardless of my search_path? Read the documentation for search_path: if pg_catalog isn't explicitly mentioned, we add it implicitly. This is mainly because it would be contrary to SQL spec (and pretty useless to boot) to not recognize the standard functions and operators. But beyond that hack, there is no mechanism other than search_path that determines what's visible or not. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Josh Berkus writes: > >> But I may be trying to push water up a hill, so, I can live with > >> adding \dfU and keeping \df as-was. > > > BTW, why the capital? \dfu is *considerably* easier to type than \dfU. > > Because (1) its counterpart S is capitalized by historical tradition, > and (2) we are going to apply this to all the variants of \d so we'd > have a conflict with \du. (Even if we special-cased our way out of the > actual conflict, there would certainly be user confusion there.) > > Also (3) you are not actually going to use this as much as you think > you are, so saving a shift keypress is not the be-all and end-all. Well, and (4), you could always 'remap' it, if you will: -- obviously with \\dfU if it gets added postgres*=> \set df '\\df' postgres*=> :df List of functions [...] I use ':r' for 'rollback;' all the time (not my idea, someone on IRC), but a : tends to be as easy for me as \. I wouldn't complain about a more generic aliasing ability in psql, mind you. Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh, * Josh Berkus (j...@agliodbs.com) wrote: >> On a seperate (kind of) note, I'd really like to be able to say "I want >> this function visible everywhere" like a system function. public really >> doesn't fit this bill very well, in my experience. > > We're *so* not going there. If you really want this, just log in as > superuser and add the functions to pg_catalog. Perhaps I didn't consider that out of sheer paranoia, but now that you've mentioned it, I'm not inherently against doing it if it'd work and not cause me more headaches than what I've got today. As I mentioned in my other email, this is mainly for PostGIS, but it can certainly apply to other modules. Is this what we would recommend as an approach for these kinds of modules? I feel like that would give -hackers, or perhaps the PostGIS people, some heartburn, but maybe I'm wrong? Still doesn't solve my complaint about being unable to keep the functions from different modules seperate, but that's true regardless of using pg_catalog or public, so this could at least be a net improvment. Comments? Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh Berkus writes: >> But I may be trying to push water up a hill, so, I can live with >> adding \dfU and keeping \df as-was. > BTW, why the capital? \dfu is *considerably* easier to type than \dfU. Because (1) its counterpart S is capitalized by historical tradition, and (2) we are going to apply this to all the variants of \d so we'd have a conflict with \du. (Even if we special-cased our way out of the actual conflict, there would certainly be user confusion there.) Also (3) you are not actually going to use this as much as you think you are, so saving a shift keypress is not the be-all and end-all. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On a seperate (kind of) note, I'd really like to be able to say "I want
> > this function visible everywhere" like a system function.
>
> Huh? System functions don't have that property either.
Perhaps I'm missing something, or it was a poor choice of words,
but:
postgres=> show search_path;
search_path
"$user",public
(1 row)
postgres*=> \df abstime
...
pg_catalog | abstime | abstime | timestamp without time zone
...
postgres*=> select abstime('2008-10-10');
abstime
2008-10-10 00:00:00-04
(1 row)
Regardless of what I reset my search_path to, I'm going to have access
to abstime. Is there something else special about it besides being
a 'system function' and being in pg_catalog to make it always available
regardless of my search_path?
> You could do that today with a quick hack on your default search path,
> though: set search_path = global, pg_catalog, public or something like
> that (... and be *very* careful about what you put in schema "global").
I reset my search_path all the time going between different tasks,
different projects, etc, and it gets really annoying to have to include
', public;' every time I want to use a PostGIS function in my 'gis'
database. That's primairly what's driving this comment, and the fact
that I tend to like keeping the 'public' schema pristine. I would find
it much cleaner if I could drop my PostGIS functions in a 'postgis'
schema but still mark the public ones as being always available somehow.
I've got lots of functions in other schemas where I *don't* want them
globally available too, of course. And it should be something at the
level of database-owner or similar to declare functions in such a way.
The point there being that PostGIS is really an extension or a
module that, if all the stars aligned, might be part of the system
catalog some day (or the same functionality at any rate). Until then,
I'd like the ability to mimic it more closely than I can today. The
other fact being that it feels dirty to me to have to put any function
that I want globally available into the 'public' schema, thus
mish-mashing them together into one area.
I've lived with it for as long as I've been using PostGIS though, so
it's not exactly a show stopper.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
* Josh Berkus (j...@agliodbs.com) wrote: >> But I may be trying to push water up a hill, so, I can live with >> adding \dfU and keeping \df as-was. > > BTW, why the capital? \dfu is *considerably* easier to type than \dfU. I havn't got much of a preference for \dfu vs. \dfU. Either works for me. Still should list all functions on the search_path tho, just to be clear. Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
All, But I may be trying to push water up a hill, so, I can live with adding \dfU and keeping \df as-was. BTW, why the capital? \dfu is *considerably* easier to type than \dfU. \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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, Jan 15, 2009 at 8:25 PM, Tom Lane wrote: > Stephen Frost writes: >> gah, I find that to be terrible. If we wanted to compromise, I'd >> rather have \df do what it does today, to keep backwards-compat and >> not confuse users, and \dfU to do what I want 99% of the time. > > This seems to me to be the compromise most likely to dissatisfy everyone > the least ... This is more sensible than most of the alternatives that have been proposed. At least I can do what I want, even if not with exactly the easiest sequence to type. I really wonder what is so terrible about the behavrior as implemented in CVS HEAD. AFAICS, no one except maybe Tom has really specified WHY they don't like it, just that they don't like it. I'm not sure whether that's because (1) it's different, and they're used to the old way; (2) it involves typing an extra character to get the behavior they want; or (3) there's no way to search user and system functions simultaneously. I reply, with respect to (1), that the new behavior is more consistent and we'll all get used to it given time; with respect to (2), if someone is going to have to type an extra character it should be the developers, not the end-users; with respect to (3), there's nothing preventing us from adding yet another option to get that behavior. But I may be trying to push water up a hill, so, I can live with adding \dfU and keeping \df as-was. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, 2009-01-15 at 20:25 -0500, Tom Lane wrote: > Stephen Frost writes: > > gah, I find that to be terrible. If we wanted to compromise, I'd > > rather have \df do what it does today, to keep backwards-compat and > > not confuse users, and \dfU to do what I want 99% of the time. > > This seems to me to be the compromise most likely to dissatisfy everyone > the least ... I could live with that. Although I really think we should review how it interacts with search paths, but that could be a 8.5 thing. Joshua D. Drake -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen Frost writes: > gah, I find that to be terrible. If we wanted to compromise, I'd > rather have \df do what it does today, to keep backwards-compat and > not confuse users, and \dfU to do what I want 99% of the time. This seems to me to be the compromise most likely to dissatisfy everyone the least ... > On a seperate (kind of) note, I'd really like to be able to say "I want > this function visible everywhere" like a system function. Huh? System functions don't have that property either. You could do that today with a quick hack on your default search path, though: set search_path = global, pg_catalog, public or something like that (... and be *very* careful about what you put in schema "global"). 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Stephen, On a seperate (kind of) note, I'd really like to be able to say "I want this function visible everywhere" like a system function. public really doesn't fit this bill very well, in my experience. We're *so* not going there. If you really want this, just log in as superuser and add the functions to pg_catalog. --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: FWD: Re: [HACKERS] Updated backslash consistency patch
* Joshua D. Drake (j...@commandprompt.com) wrote: > I like this behavior. A lot. ditto. > That was a little irritating but I get the point. The schema functions > is not in my search path. So: That's exactly right, imv.. I've got schemas with tons of functions in them, I don't want to see every function in every schema in my database every time I do \df.. > The above is broken. If I put functions in my search path and perform a > \df I should get user functions from public and functions. Agreed, 100%. That's definitely busted. > So to me, the patch needs to be fixed. It should search whatever is in > my search path. It should further properly reflect what I am searching > on in its header (List of User Defined Functions). I agree, though the header isn't a huge deal to me. > I do not see any usefulness to searching *ALL* functions except on that > rare occasion where you do them, "Where did I create that function > again?". You can use pg_dump -s for that. or pg_proc, and doesn't information_schema have some view? > Further I would also be perfectly happy with the following behavior: > > \df does nothing but return: > > \df signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh Berkus writes: >> Well, maybe we do need to go with the \df \dfS \dfU approach. >> But I'm still convinced that setting things up so that it's impossible >> to search both classes of functions together is a seriously bad idea. > Agreed -- there are times I *want* to search the system functions, and > for less-trained users they might not know the difference between UDFs > and builtin functions, especially if they've loaded a few contrib modules. Yeah, the contrib-module point is a telling one. > Personally, I don't care that much about what Hungarian Notation we use, > as long as we try to make it consistent with \dt, \dv, \dn etc. My main > objection to requiring \dfU to get only user functions is that it's not > what we do with \dt. Well, if we were going to do anything like that, I'd want to change the behavior of \dt to match everything else. I don't see the argument why \dt's existing behavior is sacrosanct if the others aren't ... 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, 2009-01-15 at 14:32 -0800, Josh Berkus wrote: > Tom, > > Personally, I don't care that much about what Hungarian Notation we use, > as long as we try to make it consistent with \dt, \dv, \dn etc. My main > objection to requiring \dfU to get only user functions is that it's not > what we do with \dt. O.k. since Tom rightfully complained that everyone was bleating about this patch without actually trying it, I updated to head and checked it out and this is what I got: postgres=# \df List of functions Schema | Name | Result data type | Argument data types +--+--+- (0 rows) Which I admit caught me off guard. The main problem with the above is it says, "List of functions". It should say, "List of User Defined Functions" or some such thing. If I type \dfS I get the usual list of system functions. I created a user function: postgres=# create function test() returns integer AS $$select 1$$ language 'SQL'; CREATE FUNCTION And then used \df postgres=# \df List of functions Schema | Name | Result data type | Argument data types +--+--+- public | test | integer | (1 row) I like this behavior. A lot. I then created a new schema and a function inside the schema: postgres=# create schema functions; CREATE SCHEMA postgres=# create function functions.test() returns integer AS $$select 1$$ language 'SQL'; CREATE FUNCTION postgres=# \df List of functions Schema | Name | Result data type | Argument data types +--+--+- public | test | integer | (1 row) That was a little irritating but I get the point. The schema functions is not in my search path. So: postgres=# set search_path to public,functions; SET postgres=# \df List of functions Schema | Name | Result data type | Argument data types +--+--+- public | test | integer | (1 row) The above is broken. If I put functions in my search path and perform a \df I should get user functions from public and functions. postgres=# set search_path to functions; SET postgres=# \df List of functions Schema | Name | Result data type | Argument data types ---+--+--+- functions | test | integer | (1 row) Performs as expected. So to me, the patch needs to be fixed. It should search whatever is in my search path. It should further properly reflect what I am searching on in its header (List of User Defined Functions). I do not see any usefulness to searching *ALL* functions except on that rare occasion where you do them, "Where did I create that function again?". You can use pg_dump -s for that. Further I would also be perfectly happy with the following behavior: \df does nothing but return: \df 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: FWD: Re: [HACKERS] Updated backslash consistency patch
>> On the other hand, I want to look at and search my user-defined >> functions FREQUENTLY. I don't care about the system functions. If I >> type \df a*, it's not because I want to see all 6 versions of the >> absolute value function and 61 other functions, it's because I don't >> want to think hard enough to remember how I spelled the first word in >> one of my functions that I know starts with "a". > > Well, maybe we do need to go with the \df \dfS \dfU approach. > But I'm still convinced that setting things up so that it's impossible > to search both classes of functions together is a seriously bad idea. I agree - that's one thing that's definitely weird about the new behavior. Of course, we've had this problem with \dt for a while, but it is somewhat masked by the fact that \d (without t) behaves differently (which seems totally strange too, come to think about it). I think maybe we should make \dt, \df, etc. show user objects, \dtS, \dfS, etc. show system objects and pick some other glyph to mean "everything". \dfA, \df!, I don't care what it is... ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom, Well, maybe we do need to go with the \df \dfS \dfU approach. But I'm still convinced that setting things up so that it's impossible to search both classes of functions together is a seriously bad idea. Agreed -- there are times I *want* to search the system functions, and for less-trained users they might not know the difference between UDFs and builtin functions, especially if they've loaded a few contrib modules. Personally, I don't care that much about what Hungarian Notation we use, as long as we try to make it consistent with \dt, \dv, \dn etc. My main objection to requiring \dfU to get only user functions is that it's not what we do with \dt. --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: FWD: Re: [HACKERS] Updated backslash consistency patch
Robert Haas writes: > You seem to be assuming that conflicts between user-defined functions > and system functions are a common problem against which users need > protection. I have been using PostgreSQL for almost 10 years and am > not sure that I've EVER had a problem with this. Probably not, else it would be seared into your memory and you'd not be in favor of making a change that increases the odds of repeating the experience ;-) > On the other hand, I want to look at and search my user-defined > functions FREQUENTLY. I don't care about the system functions. If I > type \df a*, it's not because I want to see all 6 versions of the > absolute value function and 61 other functions, it's because I don't > want to think hard enough to remember how I spelled the first word in > one of my functions that I know starts with "a". Well, maybe we do need to go with the \df \dfS \dfU approach. But I'm still convinced that setting things up so that it's impossible to search both classes of functions together is a seriously bad idea. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
* Robert Haas (robertmh...@gmail.com) wrote: > On the other hand, I want to look at and search my user-defined > functions FREQUENTLY. I don't care about the system functions. If I > type \df a*, it's not because I want to see all 6 versions of the > absolute value function and 61 other functions, it's because I don't > want to think hard enough to remember how I spelled the first word in > one of my functions that I know starts with "a". I have to agree with this in general, to be honest. We use alot of pl/pgsql functions and having the system functions be in \df and be included in '\df a*' searches has really been annoying, not to mention that it's time consuming. I do understand Tom's concern, but I wonder if we could address is in a different way- could we WARN about functions being created which overlap with system functions at CREATE time? I'm pretty sure people don't generally do that on purpose, and if they do, they need to realize they have to treat it specially afterwards to make sure they get their function called.. > I can't imagine why it's reasonable for me to want to see a list of > only my own functions, but it's NOT reasonable for me to want to > SEARCH the list of only my own functions. I would like the ability to search system functions too, I've had occation where that's easier than going to the docs for a particular function, but my impression was that'd be possible through \dfS or something? Thanks, Stephen signature.asc Description: Digital signature
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh Berkus writes: > BTW, is this patch even under consideration for 8.4? It's already committed --- remember the start of the thread was Peter complaining that he'd already been annoyed by the new behavior. (As had I, but I'd not gotten round to complaining yet.) If we wait till after 8.4 is released to reconsider, we'll have yet another layer of backwards-compatibility issues to deal with while trying to fix 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: FWD: Re: [HACKERS] Updated backslash consistency patch
> 2. You want to write "\df something". Fine, that's not going to show > any system functions anyway, unless there are system functions that are > also selected by "something". If there are, it's not apparent to me why > it's a bad idea to show them; as I've already argued, I think not > showing them is a horrid idea, especially if they are an exact match > that will mask the user-defined function. You seem to be assuming that conflicts between user-defined functions and system functions are a common problem against which users need protection. I have been using PostgreSQL for almost 10 years and am not sure that I've EVER had a problem with this. Maybe once? On the other hand, I want to look at and search my user-defined functions FREQUENTLY. I don't care about the system functions. If I type \df a*, it's not because I want to see all 6 versions of the absolute value function and 61 other functions, it's because I don't want to think hard enough to remember how I spelled the first word in one of my functions that I know starts with "a". I can't imagine why it's reasonable for me to want to see a list of only my own functions, but it's NOT reasonable for me to want to SEARCH the list of only my own functions. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom, I'm unimpressed with the idea of a \system switch, because it will still be breaking your \df queries hours after you forgot you used it to adjust \dt. (This argument holds no matter which way you prefer as default.) H, OK. BTW, is this patch even under consideration for 8.4? If not, why are we arguing about it? We have 6 months after 8.4 comes out to work out a spec. --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: FWD: Re: [HACKERS] Updated backslash consistency patch
> You're ignoring the fact that tables and functions are different and > are used differently. In particular, most of the system catalogs are > not really meant to be used directly by users, which is surely not > true for functions and operators. > > However, having said that, I'm not averse to unifying the behavior > as long as it's done in a sensible fashion. Imposing the old behavior > of \dt on everything else is simply not that sensible fashion. Do you have another proposal? Although I agree with you that there's more of a case for a user wanting looking for system functions/operators than there is for looking for system tables, I think it's important that there is some EASY way to get only user functions, or only system functions, when that's what you want. In 8.3, you can get that for tables but not for functions, and it is a huge pain in the neck. Since there are only a limited number of characters in the alphabet, it's not going to be possible to have a two-letter sequence for everything someone might want to do. We are only talking about one extra character to get at the stuff in the system catalog, though I'm curmudgeonly enough to wish it weren't a capital letter so I could avoid having to hit the shift key. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh Berkus writes: >> You *think* you don't want to see system objects. > I'm still a consultant for a living, so I use the psql command line on a > variety of client systems a lot. And I'll tell you that 80% of the time > I use \df it's to look up the exact spelling and parameters of a > user-defined function, not a builtin. And? It seems to me there are two cases here: 1. You want to just write "\df" because there aren't a whole lot of user-defined functions. Fine, I'm okay with changing the behavior of that case to show only user-defined functions. 2. You want to write "\df something". Fine, that's not going to show any system functions anyway, unless there are system functions that are also selected by "something". If there are, it's not apparent to me why it's a bad idea to show them; as I've already argued, I think not showing them is a horrid idea, especially if they are an exact match that will mask the user-defined function. > So I'm not arguing for this patch ... I'd reject it on messy syntax > grounds, and because I think a general \system switch is cleaner ... I'm unimpressed with the idea of a \system switch, because it will still be breaking your \df queries hours after you forgot you used it to adjust \dt. (This argument holds no matter which way you prefer as default.) 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: FWD: Re: [HACKERS] Updated backslash consistency patch
I wrote: > "Robert Haas" writes: >> I'm not sure whether you're endorsing that approach or panning it, but >> -1 from me. We have always had \d or \dt for user tables and \dS or >> \dtS for system tables. No one is complaining about this AFAICS, so >> we should \df be any different? > You're ignoring the fact that tables and functions are different and > are used differently. BTW, it might be worth pointing out that \d has never worked like that; for instance "\d pg_class" gives me an answer anyway. So holding up the table behavior as a model of consistency that other \d commands should emulate is a pretty weak argument to begin with. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom, You *think* you don't want to see system objects. The first time that you waste hours trying to figure out why your function doesn't work, only to find that it conflicts with a system function that \df wasn't showing you, you'll reconsider. I'm still a consultant for a living, so I use the psql command line on a variety of client systems a lot. And I'll tell you that 80% of the time I use \df it's to look up the exact spelling and parameters of a user-defined function, not a builtin. The builtins are well-documented in the PostgreSQL docs; why would I use \df to look them up? In other words, no, I can't tell you that this patch is well-implemented (and for that matter I don't like the syntax of \dfS), but I can say that the *current* behavior is annoying and time-wasting, and always has been. It's also inconsistent with the behavior of \dt. So I'm not arguing for this patch ... I'd reject it on messy syntax grounds, and because I think a general \system switch is cleaner ... but I am arguing against rejecting the idea that we want the default behavior to show user-defined functions. --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: FWD: Re: [HACKERS] Updated backslash consistency patch
"Robert Haas" writes: > I'm not sure whether you're endorsing that approach or panning it, but > -1 from me. We have always had \d or \dt for user tables and \dS or > \dtS for system tables. No one is complaining about this AFAICS, so > we should \df be any different? The only argument I can see is that > "it's always been different", but IMHO, making it still be > inconsistent yet in a sneakier and less intuitive way doesn't seem > like a step forward. You're ignoring the fact that tables and functions are different and are used differently. In particular, most of the system catalogs are not really meant to be used directly by users, which is surely not true for functions and operators. However, having said that, I'm not averse to unifying the behavior as long as it's done in a sensible fashion. Imposing the old behavior of \dt on everything else is simply not that sensible fashion. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, Jan 15, 2009 at 3:03 PM, Josh Berkus wrote: >> The real problem here is that the 'S' suffix for \dt is a bad precedent >> for everything else. If you want consistency then we need to change >> that end of things. I think that the idea of a switch to omit system >> objects, rather than include them, might work. > > I disagree. Most users, most of the time, do not want to see system > objects. So all of the \d commands should omit system objects by default, > and we should have one consistent switch across all \d commands to include > system objects. > > Actually, I personally would prefer a *general* switch, that is: > > \system on > \system off > > ... which would turn on and off the display of system objects with all \d > commands, over extending \d with an array of Hungarian notation suffixes. I think the general switch is a good idea, because then everyone can get the behavior they want using ~/.psqlrc. But I still want the Hungarian suffixes because being able to get a different behavior just once is handy. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
Josh Berkus writes: > I disagree. Most users, most of the time, do not want to see system > objects. I remain of the opinion that this opinion is wrong, and is based on lack of experience with the committed patch. You *think* you don't want to see system objects. The first time that you waste hours trying to figure out why your function doesn't work, only to find that it conflicts with a system function that \df wasn't showing you, you'll reconsider. However, since it seems that people are willing to be vocal regardless of how much time they've spent with CVS HEAD, maybe we had better wait till we are a month or so into beta and then take up the discussion again. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom, The real problem here is that the 'S' suffix for \dt is a bad precedent for everything else. If you want consistency then we need to change that end of things. I think that the idea of a switch to omit system objects, rather than include them, might work. I disagree. Most users, most of the time, do not want to see system objects. So all of the \d commands should omit system objects by default, and we should have one consistent switch across all \d commands to include system objects. Actually, I personally would prefer a *general* switch, that is: \system on \system off ... which would turn on and off the display of system objects with all \d commands, over extending \d with an array of Hungarian notation suffixes. --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: FWD: Re: [HACKERS] Updated backslash consistency patch
"Robert Haas" writes: >> However, having said that, I'm not averse to unifying the behavior >> as long as it's done in a sensible fashion. Imposing the old behavior >> of \dt on everything else is simply not that sensible fashion. > Do you have another proposal? > Although I agree with you that there's more of a case for a user > wanting looking for system functions/operators than there is for > looking for system tables, I think it's important that there is some > EASY way to get only user functions, or only system functions, when > that's what you want. 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 Now admittedly, if your user functions are scattered across multiple schemas this doesn't provide any easy way to say "all functions starting with "sin" that are *not* system functions", but I don't see that that is such an important use-case that it trumps usability for every other purpose. If you're naming your functions in a way that conflicts with system functions, you're going to have other problems (and a \df acting as HEAD does would actually get in the way of you discovering what the root of the problem is). 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, Jan 15, 2009 at 01:06:22PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Well, this is psql and it should be easy; I am not sure > > pg_catalog.* fits that requirement. > > It should be easy for common cases, which I argue "I need to see > *only* system objects" is not. Neither is "I need to see system objects by default," despite what some people whose day job is hacking on PostgreSQL may believe. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
> BTW, it might be worth pointing out that \d has never worked like that; > for instance "\d pg_class" gives me an answer anyway. So holding up the > table behavior as a model of consistency that other \d commands should > emulate is a pretty weak argument to begin with. So in 8.3.5, which is what I currently have in front of me: \d lists all tables, sequences, views \dt lists user tables only \d *foo* shows detailed information on all user and system tables, sequences, and views that have foo in the name \dt *foo* lists (without detail) all user tables \d foo shows detailed information about foo, regardless of whether foo is a user or system object \dt foo shows detailed information about foo, provided it is a user table So it appears that \dt only switches to detail mode when given a specific object, not when given a wildcard, whereas \d switches when given either a wildcard or a specific object, and only lists when given no arguments at all. I agree that is pretty weird. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
> I think searching for both user and system stuff with a pattern is a > no-brainer. I'm not sure whether you're endorsing that approach or panning it, but -1 from me. We have always had \d or \dt for user tables and \dS or \dtS for system tables. No one is complaining about this AFAICS, so we should \df be any different? The only argument I can see is that "it's always been different", but IMHO, making it still be inconsistent yet in a sneakier and less intuitive way doesn't seem like a step forward. ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian writes: > Well, this is psql and it should be easy; I am not sure pg_catalog.* > fits that requirement. It should be easy for common cases, which I argue "I need to see *only* system objects" is not. > Right now if you do \dt you see user tables, and > \dtS shows system tables; I don't see removing 'S' as being a great > usability gain. It's removal of unnecessary complexity. These commands are teetering on the edge of being too complicated to explain already. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Rod Taylor writes: > Right now pg_catalog sneaks its way onto the search_path for everybody. That > is fine for execution but information listing like this should probably > ignore those additions. Actually, the single worst, most misleading, pernicious and dangerous aspect of the currently committed behavior is exactly that it doesn't work exactly like the search path. If I say "\df foo", it should tell me about the same function(s) I would get from "select foo(...)". As-is, it would tell me about a user-defined function even if that function is masked by a similarly named system function. I don't think that should *ever* happen. The converse is true if I have a user function masking a system function (which is also possible, though not with the default search path). So it's arguable that both 'S' and the reverse are bad ideas. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, Jan 15, 2009 at 09:49:59AM -0800, Joshua D. Drake wrote: > \df output wraps at 1024x768 which greatly limits usability as a whole. > I hadn't noticed this until today as my workstation video card exploded > and I have a temporary one that can't do more than 1024x768 with linux. > Dropping the return type from the default output would solve this > problem I think (use + to get the return type). Isn't this more of a problem for your pager? it's reasonably easy to configure this to be "less -S" which will make things look prettier for you. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> I think people use \df all the time to check the argument list, verify > >> whether they remember the function name correctly, etc. It's not for > >> "learning about" stuff you never heard of, it's for remembering details > >> (as indeed is the usage for user-defined functions too). > > > Which means my patch will work perfectly for them (because of the > > pattern), and hopefully for you. ;-) > > I can agree that it's reasonable for the default behavior with no > arguments (no pattern) to be to show only user-defined objects. > Otherwise you're going to get quite a long list, which doesn't > seem particularly useful --- and if you really want that, you can > say '*.*' so there's no loss of functionality if we change it. > > However, if we don't have that restriction when a pattern is given, > I wonder whether we need the 'S' modifier at all. If you really > want to see only system objects, there's 'pg_catalog.*', but this > doesn't seem like a case that's so common that it needs a command > modifier letter. > > So my proposal at the moment is to get rid of 'S', have the behavior > with a pattern be the same as it was before, and only change the > behavior with no pattern. Well, this is psql and it should be easy; I am not sure pg_catalog.* fits that requirement. Right now if you do \dt you see user tables, and \dtS shows system tables; I don't see removing 'S' as being a great usability gain. I think searching for both user and system stuff with a pattern is a no-brainer. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian writes: > Tom Lane wrote: >> I think people use \df all the time to check the argument list, verify >> whether they remember the function name correctly, etc. It's not for >> "learning about" stuff you never heard of, it's for remembering details >> (as indeed is the usage for user-defined functions too). > Which means my patch will work perfectly for them (because of the > pattern), and hopefully for you. ;-) I can agree that it's reasonable for the default behavior with no arguments (no pattern) to be to show only user-defined objects. Otherwise you're going to get quite a long list, which doesn't seem particularly useful --- and if you really want that, you can say '*.*' so there's no loss of functionality if we change it. However, if we don't have that restriction when a pattern is given, I wonder whether we need the 'S' modifier at all. If you really want to see only system objects, there's 'pg_catalog.*', but this doesn't seem like a case that's so common that it needs a command modifier letter. So my proposal at the moment is to get rid of 'S', have the behavior with a pattern be the same as it was before, and only change the behavior with 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote: > "Brendan Jurd" writes: > > Most people wanting to learn about which system functions are > > available will be surely be going to the manual, not using \df? > > I think people use \df all the time to check the argument list, verify > whether they remember the function name correctly, etc. It's not for > "learning about" stuff you never heard of, it's for remembering details > (as indeed is the usage for user-defined functions too). Perhaps the way to solve this problem is to change the way the output is rendered. E.g; \df output wraps at 1024x768 which greatly limits usability as a whole. I hadn't noticed this until today as my workstation video card exploded and I have a temporary one that can't do more than 1024x768 with linux. Dropping the return type from the default output would solve this problem I think (use + to get the return type). More importantly why not just have it so \df sorts like this: 1. session users functions first 2. public functions second 3. pg_catalog functions last 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom Lane wrote: > "Brendan Jurd" writes: > > Most people wanting to learn about which system functions are > > available will be surely be going to the manual, not using \df? > > I think people use \df all the time to check the argument list, verify > whether they remember the function name correctly, etc. It's not for > "learning about" stuff you never heard of, it's for remembering details > (as indeed is the usage for user-defined functions too). Which means my patch will work perfectly for them (because of the pattern), and hopefully for you. ;-) -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
"Brendan Jurd" writes: > Most people wanting to learn about which system functions are > available will be surely be going to the manual, not using \df? I think people use \df all the time to check the argument list, verify whether they remember the function name correctly, etc. It's not for "learning about" stuff you never heard of, it's for remembering details (as indeed is the usage for user-defined functions too). 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Fri, Jan 16, 2009 at 03:59:47AM +1100, Brendan Jurd wrote: > Most people wanting to learn about which system functions are > available will be surely be going to the manual, not using \df? Presently the only way you'll get a list of functions that operate on large objects is to use \df. They mirror the client side API[1] quite closely so using a combination of \df and the manual works reasonably well. -- Sam http://samason.me.uk/ [1] http://www.postgresql.org/docs/8.3/static/lo-interfaces.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
I would settle for just following the search path as set by the user. If you explicitly include pg_catalog in the search path, then you should see those settings. If you do not explicitly include pg_catalog on the search_path, then it should not find those items. Right now pg_catalog sneaks its way onto the search_path for everybody. That is fine for execution but information listing like this should probably ignore those additions. On Thu, Jan 15, 2009 at 11:50 AM, Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> I think this falls in the category of "be careful what you wish for, > >> you might get it". It is now blindingly obvious that the folks asking > >> for that had not actually lived with the behavior for any period of > >> time. > > > I got several emails thanking me for applying the patch, so there is > > clearly user-demand for 'S'. > > Were any of them from people who had actually *used* the patch for more > than five minutes? I think this is clearly a case of allowing abstract > consistency considerations to override usability. > > The real problem here is that the 'S' suffix for \dt is a bad precedent > for everything else. If you want consistency then we need to change > that end of things. I think that the idea of a switch to omit system > objects, rather than include them, might work. > >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: FWD: Re: [HACKERS] Updated backslash consistency patch
>> > The basic goal of the patch was to make 'S' consistent for all \d >> > backslash commands, and we had a lot of discussion about it, and many >> > people asked for it (I can't find my user functions). >> >> I think this falls in the category of "be careful what you wish for, >> you might get it". It is now blindingly obvious that the folks asking >> for that had not actually lived with the behavior for any period of >> time. >> >> Personally I think we should just revert the patch and go back to the >> behavior we've had for umpteen years. However, if you cannot bear to >> leave well enough alone, how about *reversing* the sense --- that is, >> default behavior is to show everything and there is an extra character >> to omit system objects? > > I got several emails thanking me for applying the patch, so there is > clearly user-demand for 'S'. I think _we_ as developers look at the > system stuff a lot but in user-land, they would rather not see it by > default. +1. It is seriously annoying that there is no easy way to see the functions that you've defined without seeing all the, ahem, crap in the system catalogs. Now maybe there should be a way to toggle the behavior, but please let's not think that everyone cares to see RI_FKey_noaction_del every time they hit \df. N! ...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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Fri, Jan 16, 2009 at 3:45 AM, Greg Sabino Mullane wrote: > The problem is that you, me, and the people we know are the only ones > who actually use \df to see system functions. 99.99% of users don't care, > or don't even know, about the system functions - but they do care about > being able to view /their/ functions. So from a usability perspective, > asking a small minority of users to learn to type an extra character is > a small price to pay for a great leap in usability for everyone else. > +1. Most people wanting to learn about which system functions are available will be surely be going to the manual, not using \df? For example if you wanted to know what functions were around for doing stuff with dates, \df date* is almost useless. Most of the functions listed are operator and index support stuff. I can't imagine anyone in userland wanting date_ne_timestamptz(), say, to show up as a result of \df. I have ocassionally used things like \do to search for the more obscure operators, but honestly most of the time when I use a \d command, all I want to see is my user-defined stuff. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think this falls in the category of "be careful what you wish for,
> >> you might get it". It is now blindingly obvious that the folks asking
> >> for that had not actually lived with the behavior for any period of
> >> time.
>
> > I got several emails thanking me for applying the patch, so there is
> > clearly user-demand for 'S'.
>
> Were any of them from people who had actually *used* the patch for more
> than five minutes? I think this is clearly a case of allowing abstract
> consistency considerations to override usability.
>
> The real problem here is that the 'S' suffix for \dt is a bad precedent
> for everything else. If you want consistency then we need to change
> that end of things. I think that the idea of a switch to omit system
> objects, rather than include them, might work.
Please test the attached patch; it reverts to pre-8.4 behavior if any
pattern is present for psql \d commands, including just a simple '*'.
--
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/describe.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.195
diff -c -c -r1.195 describe.c
*** src/bin/psql/describe.c 6 Jan 2009 23:01:57 - 1.195
--- src/bin/psql/describe.c 15 Jan 2009 16:50:45 -
***
*** 94,100
"WHERE p.proisagg\n",
gettext_noop("Description"));
! if (!showSystem)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
--- 94,100
"WHERE p.proisagg\n",
gettext_noop("Description"));
! if (!showSystem && !pattern)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
***
*** 281,287
" AND p.proargtypes[0] IS DISTINCT FROM 'pg_catalog.cstring'::pg_catalog.regtype\n"
" AND NOT p.proisagg\n");
! if (!showSystem)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
--- 281,287
" AND p.proargtypes[0] IS DISTINCT FROM 'pg_catalog.cstring'::pg_catalog.regtype\n"
" AND NOT p.proisagg\n");
! if (!showSystem && !pattern)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
***
*** 372,378
else
appendPQExpBuffer(&buf, " AND t.typname !~ '^_'\n");
! if (!showSystem)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
/* Match name pattern against either internal or external name */
--- 372,378
else
appendPQExpBuffer(&buf, " AND t.typname !~ '^_'\n");
! if (!showSystem && !pattern)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
/* Match name pattern against either internal or external name */
***
*** 427,436
gettext_noop("Result type"),
gettext_noop("Description"));
! if (!showSystem)
appendPQExpBuffer(&buf, " WHERE n.nspname <> 'pg_catalog'\n");
! processSQLNamePattern(pset.db, &buf, pattern, !showSystem, true,
"n.nspname", "o.oprname", NULL,
"pg_catalog.pg_operator_is_visible(o.oid)");
--- 427,436
gettext_noop("Result type"),
gettext_noop("Description"));
! if (!showSystem && !pattern)
appendPQExpBuffer(&buf, " WHERE n.nspname <> 'pg_catalog'\n");
! processSQLNamePattern(pset.db, &buf, pattern, !showSystem && !pattern, true,
"n.nspname", "o.oprname", NULL,
"pg_catalog.pg_operator_is_visible(o.oid)");
***
*** 620,626
" WHERE p.proisagg\n",
gettext_noop("aggregate"));
! if (!showSystem)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
--- 620,626
" WHERE p.proisagg\n",
gettext_noop("aggregate"));
! if (!showSystem && !pattern)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
***
*** 643,649
" AND NOT p.proisagg\n",
gettext_noop("function"));
! if (!showSystem)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePattern(pset.db, &buf, pattern, true, false,
--- 643,649
" AND NOT p.proisagg\n",
gettext_noop("function"));
! if (!showSystem && !pattern)
appendPQExpBuffer(&buf, " AND n.nspname <> 'pg_catalog'\n");
processSQLNamePa
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian writes: > Tom Lane wrote: >> I think this falls in the category of "be careful what you wish for, >> you might get it". It is now blindingly obvious that the folks asking >> for that had not actually lived with the behavior for any period of >> time. > I got several emails thanking me for applying the patch, so there is > clearly user-demand for 'S'. Were any of them from people who had actually *used* the patch for more than five minutes? I think this is clearly a case of allowing abstract consistency considerations to override usability. The real problem here is that the 'S' suffix for \dt is a bad precedent for everything else. If you want consistency then we need to change that end of things. I think that the idea of a switch to omit system objects, rather than include them, might work. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
On Thu, 2009-01-15 at 11:45 -0500, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > I got several emails thanking me for applying the patch, so there is > clearly user-demand for 'S'. I think _we_ as developers look at the > system stuff a lot but in user-land, they would rather not see it by > default. +1. Joshua D. Drake > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom Lane wrote: > Bruce Momjian writes: >> The basic goal of the patch was to make 'S' consistent for all \d >> backslash commands, and we had a lot of discussion about it, and many >> people asked for it (I can't find my user functions). > > I think this falls in the category of "be careful what you wish for, > you might get it". It is now blindingly obvious that the folks asking > for that had not actually lived with the behavior for any period of > time. > > Personally I think we should just revert the patch and go back to the > behavior we've had for umpteen years. However, if you cannot bear to > leave well enough alone, how about *reversing* the sense --- that is, > default behavior is to show everything and there is an extra character > to omit system objects? (apologies if I didn't read the thread carefully enough to realize what it was about - it may be that we're talking about a different behavior than I'm referring to here...) Are you saying that "\dt" should include all system tables, for example? I'd find that a very bad thing... In fact, just to chime in on the opposite side of people here, I think that having "\df" just return the user defined functions is a *good* thing, one that I've wanted. Now, if I do "\df pg_something", I'd still like it to include system ones.. But finding your own user function in the plain \df list is horrible. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > This patch has annoyed me twice in two days now, and similarly with > other people I know. Having to type \dfS now is about the worst loss of > usability in psql that I can recall. Can we reconsider or revert this? The problem is that you, me, and the people we know are the only ones who actually use \df to see system functions. 99.99% of users don't care, or don't even know, about the system functions - but they do care about being able to view /their/ functions. So from a usability perspective, asking a small minority of users to learn to type an extra character is a small price to pay for a great leap in usability for everyone else. Frankly, the previous behavior was simply broken: there was no way to see all your functions (unless they happened to live in a single schema, then you could do the non-intuituve and annoying \df schemaname.) For the record, many of the people *I* know, including many 'hackers', like this change a lot. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200901151139 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAklvaAkACgkQvJuQZxSWSshpJQCbB5LbrjuP1Q9CcYAkdh6xLnoC kSsAoLvXVnGqJLi1RfnmIgzn/VRVjF9B =Twyv -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: FWD: Re: [HACKERS] Updated backslash consistency patch
Tom Lane wrote: > Bruce Momjian writes: > > The basic goal of the patch was to make 'S' consistent for all \d > > backslash commands, and we had a lot of discussion about it, and many > > people asked for it (I can't find my user functions). > > I think this falls in the category of "be careful what you wish for, > you might get it". It is now blindingly obvious that the folks asking > for that had not actually lived with the behavior for any period of > time. > > Personally I think we should just revert the patch and go back to the > behavior we've had for umpteen years. However, if you cannot bear to > leave well enough alone, how about *reversing* the sense --- that is, > default behavior is to show everything and there is an extra character > to omit system objects? I got several emails thanking me for applying the patch, so there is clearly user-demand for 'S'. I think _we_ as developers look at the system stuff a lot but in user-land, they would rather not see it by default. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian writes: > The basic goal of the patch was to make 'S' consistent for all \d > backslash commands, and we had a lot of discussion about it, and many > people asked for it (I can't find my user functions). I think this falls in the category of "be careful what you wish for, you might get it". It is now blindingly obvious that the folks asking for that had not actually lived with the behavior for any period of time. Personally I think we should just revert the patch and go back to the behavior we've had for umpteen years. However, if you cannot bear to leave well enough alone, how about *reversing* the sense --- that is, default behavior is to show everything and there is an extra character to omit system objects? 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Heikki Linnakangas wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > >> Bruce Momjian wrote: > Here's an updated version of the psql backslash patch that should > apply cleanly to the current HEAD. To recap, this makes all the \dX > commands (most importantly to most: \df) work like \dt does, in that it > requires a \dXS to see system items. See the archives for much more > discussion on the issue. > >>> Patch applied, thanks. > >> This patch has annoyed me twice in two days now, and similarly with > >> other people I know. Having to type \dfS now is about the worst loss of > >> usability in psql that I can recall. Can we reconsider or revert this? > > > > Well, \dT is even worse. ;-) (How many users have user-defined types?) > > > > The basic goal of the patch was to make 'S' consistent for all \d > > backslash commands, and we had a lot of discussion about it, and many > > people asked for it (I can't find my user functions). It is hard to > > argue that our previous behavior was logical (though perhaps useful). > > Consistency is nice, but I'm used to typing \df pg_foobar() as well. > Could we make plain "\df" list only user functions, but "\df XXX" search > for system functions as well? And the same for all \d* commands, for the > consistency. That makes sense; let me work on that. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: Here's an updated version of the psql backslash patch that should apply cleanly to the current HEAD. To recap, this makes all the \dX commands (most importantly to most: \df) work like \dt does, in that it requires a \dXS to see system items. See the archives for much more discussion on the issue. Patch applied, thanks. This patch has annoyed me twice in two days now, and similarly with other people I know. Having to type \dfS now is about the worst loss of usability in psql that I can recall. Can we reconsider or revert this? Well, \dT is even worse. ;-) (How many users have user-defined types?) The basic goal of the patch was to make 'S' consistent for all \d backslash commands, and we had a lot of discussion about it, and many people asked for it (I can't find my user functions). It is hard to argue that our previous behavior was logical (though perhaps useful). Consistency is nice, but I'm used to typing \df pg_foobar() as well. Could we make plain "\df" list only user functions, but "\df XXX" search for system functions as well? And the same for all \d* commands, for the consistency. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Peter Eisentraut writes: > This patch has annoyed me twice in two days now, and similarly with > other people I know. Having to type \dfS now is about the worst loss of > usability in psql that I can recall. Can we reconsider or revert this? I agree, this change mostly sucks, and particularly with respect to \df. 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: FWD: Re: [HACKERS] Updated backslash consistency patch
Peter Eisentraut wrote: > Bruce Momjian wrote: > >> Here's an updated version of the psql backslash patch that should > >> apply cleanly to the current HEAD. To recap, this makes all the \dX > >> commands (most importantly to most: \df) work like \dt does, in that it > >> requires a \dXS to see system items. See the archives for much more > >> discussion on the issue. > > > > Patch applied, thanks. > > This patch has annoyed me twice in two days now, and similarly with > other people I know. Having to type \dfS now is about the worst loss of > usability in psql that I can recall. Can we reconsider or revert this? Well, \dT is even worse. ;-) (How many users have user-defined types?) The basic goal of the patch was to make 'S' consistent for all \d backslash commands, and we had a lot of discussion about it, and many people asked for it (I can't find my user functions). It is hard to argue that our previous behavior was logical (though perhaps useful). The only thing I can suggest at this point is some kind of setting that defaults to 'S' for psql \d commands, but that is going to affect \dt as well. -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut wrote: This patch has annoyed me twice in two days now, and similarly with other people I know. Having to type \dfS now is about the worst loss of usability in psql that I can recall. Can we reconsider or revert this? I'd like to second this. It makes looking for specific functions and/or other objects really awful, especially if you accidently forgot the S and you're getting to think this function doesn't even exist -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
Bruce Momjian wrote: Here's an updated version of the psql backslash patch that should apply cleanly to the current HEAD. To recap, this makes all the \dX commands (most importantly to most: \df) work like \dt does, in that it requires a \dXS to see system items. See the archives for much more discussion on the issue. Patch applied, thanks. This patch has annoyed me twice in two days now, and similarly with other people I know. Having to type \dfS now is about the worst loss of usability in psql that I can recall. Can we reconsider or revert this? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: FWD: Re: [HACKERS] Updated backslash consistency patch
> Here's an updated version of the psql backslash patch that should > apply cleanly to the current HEAD. To recap, this makes all the \dX > commands (most importantly to most: \df) work like \dt does, in that it > requires a \dXS to see system items. See the archives for much more > discussion on the issue. Patch applied, thanks. --- Greg Sabino Mullane wrote: -- Start of PGP signed section. > > > 2. the help.c patch no longer applies > > > > 3. the help.c patch breaks alignment of the help output > > Attached is a patch to fix problems 2 and 3: help.c clean application and > formatting of the output therein. I also put \z right after \dp and removed > the duplicate wording, to make it fit better, per comments in this thread. > > -- > Greg Sabino Mullane [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- 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: FWD: Re: [HACKERS] Updated backslash consistency patch
> 2. the help.c patch no longer applies
>
> 3. the help.c patch breaks alignment of the help output
Attached is a patch to fix problems 2 and 3: help.c clean application and
formatting of the output therein. I also put \z right after \dp and removed
the duplicate wording, to make it fit better, per comments in this thread.
--
Greg Sabino Mullane
Index: command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.196
diff -c -r1.196 command.c
*** command.c 15 Sep 2008 12:18:00 - 1.196
--- command.c 8 Nov 2008 16:55:19 -
***
*** 329,341
else if (cmd[0] == 'd')
{
char *pattern;
! bool show_verbose;
/* We don't do SQLID reduction on the pattern yet */
pattern = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
switch (cmd[1])
{
--- 329,342
else if (cmd[0] == 'd')
{
char *pattern;
! bool show_verbose, show_system;
/* We don't do SQLID reduction on the pattern yet */
pattern = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
+ show_system = strchr(cmd, 'S') ? true: false;
switch (cmd[1])
{
***
*** 345,372
success = describeTableDetails(pattern, show_verbose);
else
/* standard listing of interesting things */
! success = listTables("tvs", NULL, show_verbose);
break;
case 'a':
! success = describeAggregates(pattern, show_verbose);
break;
case 'b':
success = describeTablespaces(pattern, show_verbose);
break;
case 'c':
! success = listConversions(pattern);
break;
case 'C':
success = listCasts(pattern);
break;
case 'd':
! success = objectDescription(pattern);
break;
case 'D':
! success = listDomains(pattern);
break;
case 'f':
! success = describeFunctions(pattern, show_verbose);
break;
case 'g':
/* no longer distinct from \du */
--- 346,373
success = describeTableDetails(pattern, show_verbose);
else
/* standard listing of interesting things */
! success = listTables("tvs", NULL, show_verbose, show_system);
break;
case 'a':
! success = describeAggregates(pattern, show_verbose, show_system);
break;
case 'b':
success = describeTablespaces(pattern, show_verbose);
break;
case 'c':
! success = listConversions(pattern, show_system);
break;
case 'C':
success = listCasts(pattern);
break;
case 'd':
! success = objectDescription(pattern, show_system);
break;
case 'D':
! success = listDomains(pattern, show_system);
break;
case 'f':
! success = describeFunctions(pattern, show_verbose, show_system);
break;
case 'g':
/* no longer distinct from \du */
***
*** 379,398
success = listSchemas(pattern, show_verbose);
break;
case 'o':
! success = describeOperators(pattern);
break;
case 'p':
success = permissionsList(pattern);
break;
case 'T':
! success = describeTypes(pattern, show_verbose);
break;
case 't':
case 'v':
case 'i':
case 's':
case 'S':
! success = listTables(&cmd[1], pattern, show_verbose);
break;
case 'u':
success = describeRoles(pattern, show_verbose);
--- 380,399
success = listSchemas(pattern, show_verbose);
break;
case 'o':
! success = describeOperators(pattern, show_system);
break;
case 'p':
success = permissionsList(pattern);
break;
case 'T':
! success = describeTypes(pattern, show_verbose, show_system);
break;
case 't':
case 'v':
case 'i':
case 's':
case 'S':
! success = listTables(&cmd[1], pattern, show_verbose, show_system);
break;
case 'u':
success = describeRoles(pattern, show_verbose);
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.187
diff -c -r1.187 describe.c
*** describe.c 6 Nov 2008 15:18:35 - 1.187
--- describe.c 8 Nov 2008 16:55:19 -
***
*** 52,58
* Takes an optional regexp to select particular aggregates
*/
bool
! describeAggregates(const char *pattern, bool verbose)
{
PQExpBufferData buf;
PGresult *res;
--- 52,58
* Takes an optional regexp to select particular aggregates
*/
bool
! describeAggregates(const char *pattern, bool verbose, bool showSystem)
{
PQExpBufferData buf;
PGresult *res;
***
*** 75,81
"ELSE\n"
"pg_catalog.array_to_string(ARRAY(\n"
" SELECT\n"
!
