Thread: 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 greg@turnstep.com PGP Key: 0x14964AC8 200505261242 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFClfyjvJuQZxSWSsgRAv4aAJ48KPwfzYGpU80KcjS9/obMqKMK0wCgx+M0 hCAJLpFXpj72anOnb+2E0yg= =ezLT -----END PGP SIGNATURE-----
Attachment
Greg Sabino Mullane <greg@turnstep.com> 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
Tom Lane wrote: > Greg Sabino Mullane <greg@turnstep.com> 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/
On Fri, 2005-05-27 at 03:45, Peter Eisentraut wrote:
> Tom Lane wrote:
> > Greg Sabino Mullane <greg@turnstep.com> 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
Robert Treat <xzilla@users.sourceforge.net> 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
On Fri, May 27, 2005 at 01:58:05PM -0400, Robert Treat wrote: > On Fri, 2005-05-27 at 03:45, Peter Eisentraut wrote: > > Tom Lane wrote: > > > Greg Sabino Mullane <greg@turnstep.com> 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. How about a psql config option? It should default to show only non-system objects, as that is the most generally useful behavior. -- Alvaro Herrera (<alvherre[a]surnet.cl>) A male gynecologist is like an auto mechanic who never owned a car. (Carrie Snow)
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. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Alvaro Herrera <alvherre@surnet.cl> 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 ;-)
regards, tom lane
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
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/msg00009.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
On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@surnet.cl> 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"
Robert Treat <xzilla@users.sourceforge.net> 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/msg00009.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
Alvaro Herrera <alvherre@surnet.cl> 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
On Friday 27 May 2005 20:45, Tom Lane wrote:
> Alvaro Herrera <alvherre@surnet.cl> 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
Robert Treat <xzilla@users.sourceforge.net> 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
On Saturday 28 May 2005 11:12, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> 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
-----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).
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200505280549
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFCmD+3vJuQZxSWSsgRAreqAKC/EekFZeLA1zGzo0LgDXSbTKRNuwCgsCWH
jLLj4ySNlsDWeY1MCdbDlNk=
=RbHQ
-----END PGP SIGNATURE-----
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
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/