Re: [PATCHES] psql backslash consistency
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Could we have a way to turn this off? At least for functions and
operators? For my usage, at least, this will be a serious step
backwards in usefulness
But all we are asking is that you add a single letter ('S') to your
queries. There are probably only a handful of people besides yourself
who use \df to look up system functions, while the other 99% of the world
would benefit greatly from being able to do a \df and see their functions,
as opposed to doing \df public.* (which won't work of course if you have
your functions in other schemas).
I am thinking we need a non-system modifier like U (user) that will only
show only user functions, operators, etc. With that, we can default the
backslash commands to be the most convenient default, and it can be
over-ridden.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] psql backslash consistency
Greg Sabino Mullane wrote:
But all we are asking is that you add a single letter ('S') to your
queries. There are probably only a handful of people besides yourself
who use \df to look up system functions, while the other 99% of the
world would benefit greatly from being able to do a \df and see their
functions, as opposed to doing \df public.* (which won't work of
course if you have your functions in other schemas).
Several years ago, \df was considered the primary documentation for what
functions existed and what they did, as the full documentation was not
all that complete back then. That's why all functions tend to have
comments defined by default. Now I don't look up functions as much as
I used to, probably because I know most of them, but I can imagine that
this original purpose of \df is still valid today.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql backslash consistency
On Friday 27 May 2005 20:45, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote:
There seems to be a distinct lack of unanimity about that judgment ;-)
Well, yes, _across Postgres hackers_. But if we were to ask
pgsql-general I have a feeling we would measure more weight on one side.
Yeah, but which side ;-) ? I think the pg-general population would have
a very much higher fraction of people who have no user-defined functions
and therefore would see no value in \df not showing system functions.
Given that a good majority of the system functions aren't even documented, I
think you'd find it more likely people would sway toward not having the few
functions they have written not be totally hidden within the vast list of
system functions that a majority of people will never make use of. As a
point of reference, both pgadmin and phppgadmin default to the hide system
functions method and I haven't seen too many complaints.
If we put in a config variable, that at least lowers the stakes for the
losing side in the argument about what the default should be. Without
that, I think there will be some serious flamewars ahead...
I'm not against the idea of a config variable, but this is what, the third or
fourth go around on this? It seems rather unfair to put this burden upon the
current patch writer at this stage of the game if someone wants to code
the config option let them, put it shouldn't be a barrier to having the
current patch be applied.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] psql backslash consistency
Robert Treat [EMAIL PROTECTED] writes: I'm not against the idea of a config variable, but this is what, the third or fourth go around on this? It seems rather unfair to put this burden upon the current patch writer at this stage of the game... The fact that objections keep being raised should suggest to you that the idea is not uncontroversial. I think it's necessary to look for a compromise that everyone can live with. You're really wasting your breath to repeat the same arguments over and over and expect that anyone's mind will change. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] psql backslash consistency
On Saturday 28 May 2005 11:12, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm not against the idea of a config variable, but this is what, the
third or fourth go around on this? It seems rather unfair to put this
burden upon the current patch writer at this stage of the game...
The fact that objections keep being raised should suggest to you that
the idea is not uncontroversial. I think it's necessary to look for a
compromise that everyone can live with. You're really wasting your
breath to repeat the same arguments over and over and expect that
anyone's mind will change.
I haven't heard a new objection yet that was discussed the previous several go
arounds, and yet here we are adding yet another precondition...
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] psql backslash consistency
Tom Lane wrote: Greg Sabino Mullane [EMAIL PROTECTED] writes: Attached is my backslash consistency patch which basically makes all the backslash commands behave as \dt does: \d* shows non-system objects, and \d*S shows system objects. Could we have a way to turn this off? At least for functions and operators? For my usage, at least, this will be a serious step backwards in usefulness. I see hardly any use case for showing only user-defined functions or types by default. I think consistency is not necessarily desirable here. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] psql backslash consistency
On Fri, 2005-05-27 at 03:45, Peter Eisentraut wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Attached is my backslash consistency patch which basically makes
all the backslash commands behave as \dt does: \d* shows non-system
objects, and \d*S shows system objects.
Could we have a way to turn this off? At least for functions and
operators? For my usage, at least, this will be a serious step
backwards in usefulness.
Do you have an implementation in mind? I'm having trouble coming up with
a way to do it cleanly.
I see hardly any use case for showing only user-defined functions or
types by default. I think consistency is not necessarily desirable
here.
See the archives for previous discussion and/or use cases.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] psql backslash consistency
Robert Treat [EMAIL PROTECTED] writes: Do you have an implementation in mind? I'm having trouble coming up with a way to do it cleanly. A psql \set variable to choose the behavior seems like a reasonable compromise. Perhaps it could list the \d commands that should include system objects by default --- that would give considerable customization flexibility. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] psql backslash consistency
Peter Eisentraut wrote: Robert Treat wrote: I see hardly any use case for showing only user-defined functions or types by default. I think consistency is not necessarily desirable here. See the archives for previous discussion and/or use cases. I didn't find any. Nevertheless, while there are undoubtedly some uses for everything, making this the default behavior does not seem acceptable. I think the logical issue is that a database with no user tables is useless/empty, so showing only user tables makes sense, while a database with no user functions is still useful, and in fact I would think most databases have no user functions. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql backslash consistency
On Friday 27 May 2005 15:09, Peter Eisentraut wrote:
Robert Treat wrote:
I see hardly any use case for showing only user-defined functions
or types by default. I think consistency is not necessarily
desirable here.
See the archives for previous discussion and/or use cases.
I didn't find any. Nevertheless, while there are undoubtedly some uses
for everything, making this the default behavior does not seem
acceptable.
ISTM it is more acceptable than you're willing to admit.
http://archives.postgresql.org/pgsql-hackers/2005-04/msg9.php
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00102.php
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00199.php
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] psql backslash consistency
On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: How about a psql config option? It should default to show only non-system objects, as that is the most generally useful behavior. There seems to be a distinct lack of unanimity about that judgment ;-) Well, yes, _across Postgres hackers_. But if we were to ask pgsql-general I have a feeling we would measure more weight on one side. Now, with your suggestion of having a config entry which would allow to set the default independently for each kind of object, maybe we should consider setting different defaults for each: for example, user-only for tables and functions, but user-and-system for operators. -- Alvaro Herrera (alvherre[a]surnet.cl) Si quieres ser creativo, aprende el arte de perder el tiempo ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] psql backslash consistency
Robert Treat [EMAIL PROTECTED] writes: On Friday 27 May 2005 15:09, Peter Eisentraut wrote: I didn't find any. Nevertheless, while there are undoubtedly some uses for everything, making this the default behavior does not seem acceptable. ISTM it is more acceptable than you're willing to admit. http://archives.postgresql.org/pgsql-hackers/2005-04/msg9.php http://archives.postgresql.org/pgsql-hackers/2005-04/msg00102.php http://archives.postgresql.org/pgsql-hackers/2004-09/msg00199.php As near as I can tell, opinion is divided about fifty-fifty among those who have bothered to weigh in ... which is hardly a strong case for making an enforced change in long-standing behavior (since those who want a change have more of an incentive to say so than those who don't). A customization variable is definitely sounding like the way to go if we're going to do anything here. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql backslash consistency
Alvaro Herrera [EMAIL PROTECTED] writes: On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote: There seems to be a distinct lack of unanimity about that judgment ;-) Well, yes, _across Postgres hackers_. But if we were to ask pgsql-general I have a feeling we would measure more weight on one side. Yeah, but which side ;-) ? I think the pg-general population would have a very much higher fraction of people who have no user-defined functions and therefore would see no value in \df not showing system functions. If we put in a config variable, that at least lowers the stakes for the losing side in the argument about what the default should be. Without that, I think there will be some serious flamewars ahead... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] psql backslash consistency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is my backslash consistency patch which basically makes all
the backslash commands behave as \dt does: \d* shows non-system objects,
and \d*S shows system objects. See the archives for more discussion on
this. I wrote this patch some time ago, and have been meaning to work on
enhancing the tab-completion stuff more. However, I'm going to leave it
as it is for now[1], and I've updated my patch to the recent cvs. This
was done hastily, so it definitely needs a looking over.
[1] I'd like to eventually fix psql so that \di [tab] only lists schemas
that actually contain possible indexes (or indexes), rather than the
current behavior which is to just list all schemas.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200505261242
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-
iD8DBQFClfyjvJuQZxSWSsgRAv4aAJ48KPwfzYGpU80KcjS9/obMqKMK0wCgx+M0
hCAJLpFXpj72anOnb+2E0yg=
=ezLT
-END PGP SIGNATURE-
Index: command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.143
diff -c -r1.143 command.c
*** command.c 29 Apr 2005 13:42:20 - 1.143
--- command.c 26 May 2005 20:09:37 -
***
*** 298,310
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])
{
--- 298,311
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])
{
***
*** 314,341
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':
success = describeGroups(pattern);
--- 315,342
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':
success = describeGroups(pattern);
***
*** 347,366
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 = describeUsers(pattern);
--- 348,367
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 = describeUsers(pattern);
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.115
diff -c
Re: [PATCHES] psql backslash consistency
Greg Sabino Mullane [EMAIL PROTECTED] writes: Attached is my backslash consistency patch which basically makes all the backslash commands behave as \dt does: \d* shows non-system objects, and \d*S shows system objects. Could we have a way to turn this off? At least for functions and operators? For my usage, at least, this will be a serious step backwards in usefulness. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
