Re: FWD: Re: Updated backslash consistency patch

Lists: pgsql-hackers
From: Greg Sabino Mullane <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2008-11-08 17:09:42
Message-ID: 20081108120942.5b3b9bbe@greg-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


> 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 Content-Type Size
backslash_consistency.v2.patch text/x-patch 21.8 KB

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-06 21:11:57
Message-ID: 200901062111.n06LBve29252@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 15:51:35
Message-ID: 496F5B87.9060003@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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?


From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:04:44
Message-ID: 3ED6668CE2C9E720C63A64B7@teje
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut
<peter_e(at)gmx(dot)net> 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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:11:31
Message-ID: 200901151611.n0FGBVh17219@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:16:44
Message-ID: 6751.1232036204@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> 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


From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:18:18
Message-ID: 496F61CA.60707@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:25:23
Message-ID: 200901151625.n0FGPNo23249@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:39:17
Message-ID: 7175.1232037557@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> 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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:45:09
Message-ID: 200901151645.n0FGj9307709@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:45:23
Message-ID: f3cfdea2edc3f8b5147d6cc0bdcbd7a9@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


-----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 greg(at)turnstep(dot)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-----


From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:46:49
Message-ID: 496F6879.1000305@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:49:04
Message-ID: 1232038144.16810.9.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, 2009-01-15 at 11:45 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:50:46
Message-ID: 7445.1232038246@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> 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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:56:38
Message-ID: 200901151656.n0FGucc12881@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/pgpatches/psql text/x-diff 10.2 KB

From: Rod Taylor <rod(dot)taylor(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:59:35
Message-ID: 751261b20901150859j320b2badg424f491c2acd475a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Bruce Momjian <bruce(at)momjian(dot)us> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


From: "Brendan Jurd" <direvus(at)gmail(dot)com>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 16:59:47
Message-ID: 37ed240d0901150859k1dc9dd8dn4c5717237284adfb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Jan 16, 2009 at 3:45 AM, Greg Sabino Mullane <greg(at)turnstep(dot)com> 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


From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:24:33
Message-ID: 603c8f070901150924u440e70a4g5bfca06cc349382c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>> > 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. Noooo!

...Robert


From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:32:44
Message-ID: 20090115173244.GL3008@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Brendan Jurd" <direvus(at)gmail(dot)com>
Cc: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:36:48
Message-ID: 8270.1232041008@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Brendan Jurd" <direvus(at)gmail(dot)com> 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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:41:18
Message-ID: 200901151741.n0FHfI816268@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> "Brendan Jurd" <direvus(at)gmail(dot)com> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:49:59
Message-ID: 1232041799.21285.8.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote:
> "Brendan Jurd" <direvus(at)gmail(dot)com> 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: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:50:24
Message-ID: 8545.1232041824@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> 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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:54:53
Message-ID: 200901151754.n0FHsrg18619@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 17:55:11
Message-ID: 20090115175511.GN3008@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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/


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <rod(dot)taylor(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:01:15
Message-ID: 8760.1232042475@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Rod Taylor <rod(dot)taylor(at)gmail(dot)com> 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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:06:22
Message-ID: 8858.1232042782@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> 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


From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:08:51
Message-ID: 603c8f070901151008y24b8a5d0v360c0005865c8f09@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:23:19
Message-ID: 9117.1232043799@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Robert Haas" <robertmhaas(at)gmail(dot)com> 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


From: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 18:25:42
Message-ID: 653496D0-5C9B-4C7C-835C-82314C4F5F66@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

How many of the people who find the new behaviour are mainly postgres
hackers and not users?

I remember finding the behaviour *very* frustrating when I was a user
and was mainly concerned with maintaining my own functions. I hardly
ever used \df for system functions.

Now the situation is reversed - I mainly work with test databases with
simple schemas. But it's common for users to have hundreds of
functions - and much more likely that they would want to look them up
by name.

--
Greg

On 15 Jan 2009, at 16:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Bruce Momjian <bruce(at)momjian(dot)us> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 18:34:15
Message-ID: 1232044455.12600.205.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, 2009-01-15 at 18:25 +0000, Greg Stark wrote:
> How many of the people who find the new behaviour are mainly postgres
> hackers and not users?
>
> I remember finding the behaviour *very* frustrating when I was a user
> and was mainly concerned with maintaining my own functions. I hardly
> ever used \df for system functions.
>
> Now the situation is reversed - I mainly work with test databases with
> simple schemas. But it's common for users to have hundreds of
> functions - and much more likely that they would want to look them up
> by name.

Very well said Greg. To add to this, I find that sometimes an
illustration of the problem is useful. Below is the \df of a sample
postgres database. Notice that the first 1854 entries are pg_catalog
entries.

How in any way is that manageable when what I want to see my functions?

I know I already posted this but it seems the most useful behavior is to
just change the sort. It doesn't change any behavior in terms of
flags/switches so there is nothing new to learn. It just changes the
output.

List of functions
Schema | Name | Result
data type |
Argument data
types
------------+----------------------------------------------+-----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pg_catalog | RI_FKey_cascade_del | trigger
|
pg_catalog | RI_FKey_cascade_upd | trigger
|
pg_catalog | RI_FKey_check_ins | trigger
|
pg_catalog | RI_FKey_check_upd | trigger
|
pg_catalog | RI_FKey_noaction_del | trigger
|
pg_catalog | RI_FKey_noaction_upd | trigger
|
pg_catalog | RI_FKey_restrict_del | trigger
|
pg_catalog | RI_FKey_restrict_upd | trigger
|
pg_catalog | RI_FKey_setdefault_del | trigger
|
pg_catalog | RI_FKey_setdefault_upd | trigger
|
pg_catalog | RI_FKey_setnull_del | trigger
|
pg_catalog | RI_FKey_setnull_upd | trigger
|
pg_catalog | abbrev | text
| cidr
pg_catalog | abbrev | text
| inet
pg_catalog | abs | bigint
| bigint
pg_catalog | abs | double
precision | double precision
pg_catalog | abs | integer
| integer
pg_catalog | abs | numeric
| numeric
pg_catalog | abs | real
| real
pg_catalog | abs | smallint
| smallint
pg_catalog | abstime | abstime
| timestamp without time zone
pg_catalog | abstime | abstime
| timestamp with time zone
pg_catalog | abstimeeq | boolean
| abstime, abstime
pg_catalog | abstimege | boolean
| abstime, abstime
pg_catalog | abstimegt | boolean
| abstime, abstime
pg_catalog | abstimele | boolean
| abstime, abstime
pg_catalog | abstimelt | boolean
| abstime, abstime
pg_catalog | abstimene | boolean
| abstime, abstime
pg_catalog | abstimerecv | abstime
| internal
pg_catalog | abstimesend | bytea
| abstime
pg_catalog | aclcontains | boolean
| aclitem[], aclitem
pg_catalog | aclinsert | aclitem[]
| aclitem[], aclitem
pg_catalog | aclitemeq | boolean
| aclitem, aclitem
pg_catalog | aclremove | aclitem[]
| aclitem[], aclitem
pg_catalog | acos | double
precision | double precision
pg_catalog | age | integer
| xid
pg_catalog | age | interval
| timestamp without time zone
pg_catalog | age | interval
| timestamp without time zone, timestamp without time zone
pg_catalog | age | interval
| timestamp with time zone
pg_catalog | age | interval
| timestamp with time zone, timestamp with time zone
pg_catalog | anyarray_recv | anyarray
| internal
pg_catalog | anyarray_send | bytea
| anyarray
pg_catalog | anytextcat | text
| anynonarray, text
pg_catalog | area | double
precision | box
pg_catalog | area | double
precision | circle
pg_catalog | area | double
precision | path
pg_catalog | areajoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | areasel | double
precision | internal, oid, internal, integer
pg_catalog | array_append | anyarray
| anyarray, anyelement
pg_catalog | array_cat | anyarray
| anyarray, anyarray
pg_catalog | array_dims | text
| anyarray
pg_catalog | array_eq | boolean
| anyarray, anyarray
pg_catalog | array_ge | boolean
| anyarray, anyarray
pg_catalog | array_gt | boolean
| anyarray, anyarray
pg_catalog | array_larger | anyarray
| anyarray, anyarray
pg_catalog | array_le | boolean
| anyarray, anyarray
pg_catalog | array_lower | integer
| anyarray, integer
pg_catalog | array_lt | boolean
| anyarray, anyarray
pg_catalog | array_ne | boolean
| anyarray, anyarray
pg_catalog | array_prepend | anyarray
| anyelement, anyarray
pg_catalog | array_recv | anyarray
| internal, oid, integer
pg_catalog | array_send | bytea
| anyarray
pg_catalog | array_smaller | anyarray
| anyarray, anyarray
pg_catalog | array_to_string | text
| anyarray, text
pg_catalog | array_upper | integer
| anyarray, integer
pg_catalog | arraycontained | boolean
| anyarray, anyarray
pg_catalog | arraycontains | boolean
| anyarray, anyarray
pg_catalog | arrayoverlap | boolean
| anyarray, anyarray
pg_catalog | ascii | integer
| text
pg_catalog | ascii_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | ascii_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | asin | double
precision | double precision
pg_catalog | atan | double
precision | double precision
pg_catalog | atan2 | double
precision | double precision, double precision
pg_catalog | big5_to_euc_tw | void
| integer, integer, cstring, internal, integer
pg_catalog | big5_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | big5_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | bit | bit
| bigint, integer
pg_catalog | bit | bit
| bit, integer, boolean
pg_catalog | bit | bit
| integer, integer
pg_catalog | bit_length | integer
| bit
pg_catalog | bit_length | integer
| bytea
pg_catalog | bit_length | integer
| text
pg_catalog | bit_recv | bit
| internal, oid, integer
pg_catalog | bit_send | bytea
| bit
pg_catalog | bitand | bit
| bit, bit
pg_catalog | bitcat | bit varying
| bit varying, bit varying
pg_catalog | bitcmp | integer
| bit, bit
pg_catalog | biteq | boolean
| bit, bit
pg_catalog | bitge | boolean
| bit, bit
pg_catalog | bitgt | boolean
| bit, bit
pg_catalog | bitle | boolean
| bit, bit
pg_catalog | bitlt | boolean
| bit, bit
pg_catalog | bitne | boolean
| bit, bit
pg_catalog | bitnot | bit
| bit
pg_catalog | bitor | bit
| bit, bit
pg_catalog | bitshiftleft | bit
| bit, integer
pg_catalog | bitshiftright | bit
| bit, integer
pg_catalog | bittypmodin | integer
| cstring[]
pg_catalog | bitxor | bit
| bit, bit
pg_catalog | bool | boolean
| integer
pg_catalog | booland_statefunc | boolean
| boolean, boolean
pg_catalog | booleq | boolean
| boolean, boolean
pg_catalog | boolge | boolean
| boolean, boolean
pg_catalog | boolgt | boolean
| boolean, boolean
pg_catalog | boolle | boolean
| boolean, boolean
pg_catalog | boollt | boolean
| boolean, boolean
pg_catalog | boolne | boolean
| boolean, boolean
pg_catalog | boolor_statefunc | boolean
| boolean, boolean
pg_catalog | boolrecv | boolean
| internal
pg_catalog | boolsend | bytea
| boolean
pg_catalog | box | box
| circle
pg_catalog | box | box
| point, point
pg_catalog | box | box
| polygon
pg_catalog | box_above | boolean
| box, box
pg_catalog | box_above_eq | boolean
| box, box
pg_catalog | box_add | box
| box, point
pg_catalog | box_below | boolean
| box, box
pg_catalog | box_below_eq | boolean
| box, box
pg_catalog | box_center | point
| box
pg_catalog | box_contain | boolean
| box, box
pg_catalog | box_contained | boolean
| box, box
pg_catalog | box_distance | double
precision | box, box
pg_catalog | box_div | box
| box, point
pg_catalog | box_eq | boolean
| box, box
pg_catalog | box_ge | boolean
| box, box
pg_catalog | box_gt | boolean
| box, box
pg_catalog | box_intersect | box
| box, box
pg_catalog | box_le | boolean
| box, box
pg_catalog | box_left | boolean
| box, box
pg_catalog | box_lt | boolean
| box, box
pg_catalog | box_mul | box
| box, point
pg_catalog | box_overabove | boolean
| box, box
pg_catalog | box_overbelow | boolean
| box, box
pg_catalog | box_overlap | boolean
| box, box
pg_catalog | box_overleft | boolean
| box, box
pg_catalog | box_overright | boolean
| box, box
pg_catalog | box_recv | box
| internal
pg_catalog | box_right | boolean
| box, box
pg_catalog | box_same | boolean
| box, box
pg_catalog | box_send | bytea
| box
pg_catalog | box_sub | box
| box, point
pg_catalog | bpchar | character
| "char"
pg_catalog | bpchar | character
| character, integer, boolean
pg_catalog | bpchar | character
| name
pg_catalog | bpchar_larger | character
| character, character
pg_catalog | bpchar_pattern_eq | boolean
| character, character
pg_catalog | bpchar_pattern_ge | boolean
| character, character
pg_catalog | bpchar_pattern_gt | boolean
| character, character
pg_catalog | bpchar_pattern_le | boolean
| character, character
pg_catalog | bpchar_pattern_lt | boolean
| character, character
pg_catalog | bpchar_pattern_ne | boolean
| character, character
pg_catalog | bpchar_smaller | character
| character, character
pg_catalog | bpcharcmp | integer
| character, character
pg_catalog | bpchareq | boolean
| character, character
pg_catalog | bpcharge | boolean
| character, character
pg_catalog | bpchargt | boolean
| character, character
pg_catalog | bpchariclike | boolean
| character, text
pg_catalog | bpcharicnlike | boolean
| character, text
pg_catalog | bpcharicregexeq | boolean
| character, text
pg_catalog | bpcharicregexne | boolean
| character, text
pg_catalog | bpcharle | boolean
| character, character
pg_catalog | bpcharlike | boolean
| character, text
pg_catalog | bpcharlt | boolean
| character, character
pg_catalog | bpcharne | boolean
| character, character
pg_catalog | bpcharnlike | boolean
| character, text
pg_catalog | bpcharrecv | character
| internal, oid, integer
pg_catalog | bpcharregexeq | boolean
| character, text
pg_catalog | bpcharregexne | boolean
| character, text
pg_catalog | bpcharsend | bytea
| character
pg_catalog | bpchartypmodin | integer
| cstring[]
pg_catalog | broadcast | inet
| inet
pg_catalog | btabstimecmp | integer
| abstime, abstime
pg_catalog | btarraycmp | integer
| anyarray, anyarray
pg_catalog | btbeginscan | internal
| internal, internal, internal
pg_catalog | btboolcmp | integer
| boolean, boolean
pg_catalog | btbpchar_pattern_cmp | integer
| character, character
pg_catalog | btbuild | internal
| internal, internal, internal
pg_catalog | btbulkdelete | internal
| internal, internal, internal, internal
pg_catalog | btcharcmp | integer
| "char", "char"
pg_catalog | btcostestimate | void
| internal, internal, internal, internal, internal, internal, internal,
internal
pg_catalog | btendscan | void
| internal
pg_catalog | btfloat48cmp | integer
| real, double precision
pg_catalog | btfloat4cmp | integer
| real, real
pg_catalog | btfloat84cmp | integer
| double precision, real
pg_catalog | btfloat8cmp | integer
| double precision, double precision
pg_catalog | btgetmulti | boolean
| internal, internal, internal, internal
pg_catalog | btgettuple | boolean
| internal, internal
pg_catalog | btinsert | boolean
| internal, internal, internal, internal, internal, internal
pg_catalog | btint24cmp | integer
| smallint, integer
pg_catalog | btint28cmp | integer
| smallint, bigint
pg_catalog | btint2cmp | integer
| smallint, smallint
pg_catalog | btint42cmp | integer
| integer, smallint
pg_catalog | btint48cmp | integer
| integer, bigint
pg_catalog | btint4cmp | integer
| integer, integer
pg_catalog | btint82cmp | integer
| bigint, smallint
pg_catalog | btint84cmp | integer
| bigint, integer
pg_catalog | btint8cmp | integer
| bigint, bigint
pg_catalog | btmarkpos | void
| internal
pg_catalog | btname_pattern_cmp | integer
| name, name
pg_catalog | btnamecmp | integer
| name, name
pg_catalog | btoidcmp | integer
| oid, oid
pg_catalog | btoidvectorcmp | integer
| oidvector, oidvector
pg_catalog | btoptions | bytea
| text[], boolean
pg_catalog | btreltimecmp | integer
| reltime, reltime
pg_catalog | btrescan | void
| internal, internal
pg_catalog | btrestrpos | void
| internal
pg_catalog | btrim | bytea
| bytea, bytea
pg_catalog | btrim | text
| text
pg_catalog | btrim | text
| text, text
pg_catalog | bttext_pattern_cmp | integer
| text, text
pg_catalog | bttextcmp | integer
| text, text
pg_catalog | bttidcmp | integer
| tid, tid
pg_catalog | bttintervalcmp | integer
| tinterval, tinterval
pg_catalog | btvacuumcleanup | internal
| internal, internal
pg_catalog | byteacat | bytea
| bytea, bytea
pg_catalog | byteacmp | integer
| bytea, bytea
pg_catalog | byteaeq | boolean
| bytea, bytea
pg_catalog | byteage | boolean
| bytea, bytea
pg_catalog | byteagt | boolean
| bytea, bytea
pg_catalog | byteale | boolean
| bytea, bytea
pg_catalog | bytealike | boolean
| bytea, bytea
pg_catalog | bytealt | boolean
| bytea, bytea
pg_catalog | byteane | boolean
| bytea, bytea
pg_catalog | byteanlike | boolean
| bytea, bytea
pg_catalog | bytearecv | bytea
| internal
pg_catalog | byteasend | bytea
| bytea
pg_catalog | cash_cmp | integer
| money, money
pg_catalog | cash_div_flt4 | money
| money, real
pg_catalog | cash_div_flt8 | money
| money, double precision
pg_catalog | cash_div_int2 | money
| money, smallint
pg_catalog | cash_div_int4 | money
| money, integer
pg_catalog | cash_eq | boolean
| money, money
pg_catalog | cash_ge | boolean
| money, money
pg_catalog | cash_gt | boolean
| money, money
pg_catalog | cash_le | boolean
| money, money
pg_catalog | cash_lt | boolean
| money, money
pg_catalog | cash_mi | money
| money, money
pg_catalog | cash_mul_flt4 | money
| money, real
pg_catalog | cash_mul_flt8 | money
| money, double precision
pg_catalog | cash_mul_int2 | money
| money, smallint
pg_catalog | cash_mul_int4 | money
| money, integer
pg_catalog | cash_ne | boolean
| money, money
pg_catalog | cash_pl | money
| money, money
pg_catalog | cash_recv | money
| internal
pg_catalog | cash_send | bytea
| money
pg_catalog | cash_words | text
| money
pg_catalog | cashlarger | money
| money, money
pg_catalog | cashsmaller | money
| money, money
pg_catalog | cbrt | double
precision | double precision
pg_catalog | ceil | double
precision | double precision
pg_catalog | ceil | numeric
| numeric
pg_catalog | ceiling | double
precision | double precision
pg_catalog | ceiling | numeric
| numeric
pg_catalog | center | point
| box
pg_catalog | center | point
| circle
pg_catalog | char | "char"
| integer
pg_catalog | char | "char"
| text
pg_catalog | char_length | integer
| character
pg_catalog | char_length | integer
| text
pg_catalog | character_length | integer
| character
pg_catalog | character_length | integer
| text
pg_catalog | chareq | boolean
| "char", "char"
pg_catalog | charge | boolean
| "char", "char"
pg_catalog | chargt | boolean
| "char", "char"
pg_catalog | charle | boolean
| "char", "char"
pg_catalog | charlt | boolean
| "char", "char"
pg_catalog | charne | boolean
| "char", "char"
pg_catalog | charrecv | "char"
| internal
pg_catalog | charsend | bytea
| "char"
pg_catalog | chr | text
| integer
pg_catalog | cideq | boolean
| cid, cid
pg_catalog | cidr | cidr
| inet
pg_catalog | cidr_recv | cidr
| internal
pg_catalog | cidr_send | bytea
| cidr
pg_catalog | cidrecv | cid
| internal
pg_catalog | cidsend | bytea
| cid
pg_catalog | circle | circle
| box
pg_catalog | circle | circle
| point, double precision
pg_catalog | circle | circle
| polygon
pg_catalog | circle_above | boolean
| circle, circle
pg_catalog | circle_add_pt | circle
| circle, point
pg_catalog | circle_below | boolean
| circle, circle
pg_catalog | circle_center | point
| circle
pg_catalog | circle_contain | boolean
| circle, circle
pg_catalog | circle_contain_pt | boolean
| circle, point
pg_catalog | circle_contained | boolean
| circle, circle
pg_catalog | circle_distance | double
precision | circle, circle
pg_catalog | circle_div_pt | circle
| circle, point
pg_catalog | circle_eq | boolean
| circle, circle
pg_catalog | circle_ge | boolean
| circle, circle
pg_catalog | circle_gt | boolean
| circle, circle
pg_catalog | circle_le | boolean
| circle, circle
pg_catalog | circle_left | boolean
| circle, circle
pg_catalog | circle_lt | boolean
| circle, circle
pg_catalog | circle_mul_pt | circle
| circle, point
pg_catalog | circle_ne | boolean
| circle, circle
pg_catalog | circle_overabove | boolean
| circle, circle
pg_catalog | circle_overbelow | boolean
| circle, circle
pg_catalog | circle_overlap | boolean
| circle, circle
pg_catalog | circle_overleft | boolean
| circle, circle
pg_catalog | circle_overright | boolean
| circle, circle
pg_catalog | circle_recv | circle
| internal
pg_catalog | circle_right | boolean
| circle, circle
pg_catalog | circle_same | boolean
| circle, circle
pg_catalog | circle_send | bytea
| circle
pg_catalog | circle_sub_pt | circle
| circle, point
pg_catalog | clock_timestamp | timestamp
with time zone |
pg_catalog | close_lb | point
| line, box
pg_catalog | close_ls | point
| line, lseg
pg_catalog | close_lseg | point
| lseg, lseg
pg_catalog | close_pb | point
| point, box
pg_catalog | close_pl | point
| point, line
pg_catalog | close_ps | point
| point, lseg
pg_catalog | close_sb | point
| lseg, box
pg_catalog | close_sl | point
| lseg, line
pg_catalog | col_description | text
| oid, integer
pg_catalog | contjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | contsel | double
precision | internal, oid, internal, integer
pg_catalog | convert | bytea
| bytea, name, name
pg_catalog | convert_from | text
| bytea, name
pg_catalog | convert_to | bytea
| text, name
pg_catalog | cos | double
precision | double precision
pg_catalog | cot | double
precision | double precision
pg_catalog | current_database | name
|
pg_catalog | current_schema | name
|
pg_catalog | current_schemas | name[]
| boolean
pg_catalog | current_setting | text
| text
pg_catalog | current_user | name
|
pg_catalog | currtid | tid
| oid, tid
pg_catalog | currtid2 | tid
| text, tid
pg_catalog | currval | bigint
| regclass
pg_catalog | cursor_to_xml | xml
| cursor refcursor, count integer, nulls boolean, tableforest boolean,
targetns text
pg_catalog | cursor_to_xmlschema | xml
| cursor refcursor, nulls boolean, tableforest boolean, targetns text
pg_catalog | database_to_xml | xml
| nulls boolean, tableforest boolean, targetns text
pg_catalog | database_to_xml_and_xmlschema | xml
| nulls boolean, tableforest boolean, targetns text
pg_catalog | database_to_xmlschema | xml
| nulls boolean, tableforest boolean, targetns text
pg_catalog | date | date
| abstime
pg_catalog | date | date
| timestamp without time zone
pg_catalog | date | date
| timestamp with time zone
pg_catalog | date_cmp | integer
| date, date
pg_catalog | date_cmp_timestamp | integer
| date, timestamp without time zone
pg_catalog | date_cmp_timestamptz | integer
| date, timestamp with time zone
pg_catalog | date_eq | boolean
| date, date
pg_catalog | date_eq_timestamp | boolean
| date, timestamp without time zone
pg_catalog | date_eq_timestamptz | boolean
| date, timestamp with time zone
pg_catalog | date_ge | boolean
| date, date
pg_catalog | date_ge_timestamp | boolean
| date, timestamp without time zone
pg_catalog | date_ge_timestamptz | boolean
| date, timestamp with time zone
pg_catalog | date_gt | boolean
| date, date
pg_catalog | date_gt_timestamp | boolean
| date, timestamp without time zone
pg_catalog | date_gt_timestamptz | boolean
| date, timestamp with time zone
pg_catalog | date_larger | date
| date, date
pg_catalog | date_le | boolean
| date, date
pg_catalog | date_le_timestamp | boolean
| date, timestamp without time zone
pg_catalog | date_le_timestamptz | boolean
| date, timestamp with time zone
pg_catalog | date_lt | boolean
| date, date
pg_catalog | date_lt_timestamp | boolean
| date, timestamp without time zone
pg_catalog | date_lt_timestamptz | boolean
| date, timestamp with time zone
pg_catalog | date_mi | integer
| date, date
pg_catalog | date_mi_interval | timestamp
without time zone | date, interval
pg_catalog | date_mii | date
| date, integer
pg_catalog | date_ne | boolean
| date, date
pg_catalog | date_ne_timestamp | boolean
| date, timestamp without time zone
pg_catalog | date_ne_timestamptz | boolean
| date, timestamp with time zone
pg_catalog | date_part | double
precision | text, abstime
pg_catalog | date_part | double
precision | text, date
pg_catalog | date_part | double
precision | text, interval
pg_catalog | date_part | double
precision | text, reltime
pg_catalog | date_part | double
precision | text, timestamp without time zone
pg_catalog | date_part | double
precision | text, timestamp with time zone
pg_catalog | date_part | double
precision | text, time without time zone
pg_catalog | date_part | double
precision | text, time with time zone
pg_catalog | date_pl_interval | timestamp
without time zone | date, interval
pg_catalog | date_pli | date
| date, integer
pg_catalog | date_recv | date
| internal
pg_catalog | date_send | bytea
| date
pg_catalog | date_smaller | date
| date, date
pg_catalog | date_trunc | interval
| text, interval
pg_catalog | date_trunc | timestamp
without time zone | text, timestamp without time zone
pg_catalog | date_trunc | timestamp
with time zone | text, timestamp with time zone
pg_catalog | datetime_pl | timestamp
without time zone | date, time without time zone
pg_catalog | datetimetz_pl | timestamp
with time zone | date, time with time zone
pg_catalog | dcbrt | double
precision | double precision
pg_catalog | decode | bytea
| text, text
pg_catalog | degrees | double
precision | double precision
pg_catalog | dexp | double
precision | double precision
pg_catalog | diagonal | lseg
| box
pg_catalog | diameter | double
precision | circle
pg_catalog | dispell_init | internal
| internal
pg_catalog | dispell_lexize | internal
| internal, internal, internal, internal
pg_catalog | dist_cpoly | double
precision | circle, polygon
pg_catalog | dist_lb | double
precision | line, box
pg_catalog | dist_pb | double
precision | point, box
pg_catalog | dist_pc | double
precision | point, circle
pg_catalog | dist_pl | double
precision | point, line
pg_catalog | dist_ppath | double
precision | point, path
pg_catalog | dist_ps | double
precision | point, lseg
pg_catalog | dist_sb | double
precision | lseg, box
pg_catalog | dist_sl | double
precision | lseg, line
pg_catalog | dlog1 | double
precision | double precision
pg_catalog | dlog10 | double
precision | double precision
pg_catalog | domain_recv | "any"
| internal, oid, integer
pg_catalog | dpow | double
precision | double precision, double precision
pg_catalog | dround | double
precision | double precision
pg_catalog | dsimple_init | internal
| internal
pg_catalog | dsimple_lexize | internal
| internal, internal, internal, internal
pg_catalog | dsnowball_init | internal
| internal
pg_catalog | dsnowball_lexize | internal
| internal, internal, internal, internal
pg_catalog | dsqrt | double
precision | double precision
pg_catalog | dsynonym_init | internal
| internal
pg_catalog | dsynonym_lexize | internal
| internal, internal, internal, internal
pg_catalog | dtrunc | double
precision | double precision
pg_catalog | encode | text
| bytea, text
pg_catalog | enum_cmp | integer
| anyenum, anyenum
pg_catalog | enum_eq | boolean
| anyenum, anyenum
pg_catalog | enum_first | anyenum
| anyenum
pg_catalog | enum_ge | boolean
| anyenum, anyenum
pg_catalog | enum_gt | boolean
| anyenum, anyenum
pg_catalog | enum_larger | anyenum
| anyenum, anyenum
pg_catalog | enum_last | anyenum
| anyenum
pg_catalog | enum_le | boolean
| anyenum, anyenum
pg_catalog | enum_lt | boolean
| anyenum, anyenum
pg_catalog | enum_ne | boolean
| anyenum, anyenum
pg_catalog | enum_range | anyarray
| anyenum
pg_catalog | enum_range | anyarray
| anyenum, anyenum
pg_catalog | enum_send | bytea
| anyenum
pg_catalog | enum_smaller | anyenum
| anyenum, anyenum
pg_catalog | eqjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | eqsel | double
precision | internal, oid, internal, integer
pg_catalog | euc_cn_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_cn_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_jis_2004_to_shift_jis_2004 | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_jis_2004_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_jp_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_jp_to_sjis | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_jp_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_kr_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_kr_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_tw_to_big5 | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_tw_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | euc_tw_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | exp | double
precision | double precision
pg_catalog | exp | numeric
| numeric
pg_catalog | factorial | numeric
| bigint
pg_catalog | family | integer
| inet
pg_catalog | flatfile_update_trigger | trigger
|
pg_catalog | float4 | real
| bigint
pg_catalog | float4 | real
| double precision
pg_catalog | float4 | real
| integer
pg_catalog | float4 | real
| numeric
pg_catalog | float4 | real
| smallint
pg_catalog | float48div | double
precision | real, double precision
pg_catalog | float48eq | boolean
| real, double precision
pg_catalog | float48ge | boolean
| real, double precision
pg_catalog | float48gt | boolean
| real, double precision
pg_catalog | float48le | boolean
| real, double precision
pg_catalog | float48lt | boolean
| real, double precision
pg_catalog | float48mi | double
precision | real, double precision
pg_catalog | float48mul | double
precision | real, double precision
pg_catalog | float48ne | boolean
| real, double precision
pg_catalog | float48pl | double
precision | real, double precision
pg_catalog | float4_accum | double
precision[] | double precision[], real
pg_catalog | float4abs | real
| real
pg_catalog | float4div | real
| real, real
pg_catalog | float4eq | boolean
| real, real
pg_catalog | float4ge | boolean
| real, real
pg_catalog | float4gt | boolean
| real, real
pg_catalog | float4larger | real
| real, real
pg_catalog | float4le | boolean
| real, real
pg_catalog | float4lt | boolean
| real, real
pg_catalog | float4mi | real
| real, real
pg_catalog | float4mul | real
| real, real
pg_catalog | float4ne | boolean
| real, real
pg_catalog | float4pl | real
| real, real
pg_catalog | float4recv | real
| internal
pg_catalog | float4send | bytea
| real
pg_catalog | float4smaller | real
| real, real
pg_catalog | float4um | real
| real
pg_catalog | float4up | real
| real
pg_catalog | float8 | double
precision | bigint
pg_catalog | float8 | double
precision | integer
pg_catalog | float8 | double
precision | numeric
pg_catalog | float8 | double
precision | real
pg_catalog | float8 | double
precision | smallint
pg_catalog | float84div | double
precision | double precision, real
pg_catalog | float84eq | boolean
| double precision, real
pg_catalog | float84ge | boolean
| double precision, real
pg_catalog | float84gt | boolean
| double precision, real
pg_catalog | float84le | boolean
| double precision, real
pg_catalog | float84lt | boolean
| double precision, real
pg_catalog | float84mi | double
precision | double precision, real
pg_catalog | float84mul | double
precision | double precision, real
pg_catalog | float84ne | boolean
| double precision, real
pg_catalog | float84pl | double
precision | double precision, real
pg_catalog | float8_accum | double
precision[] | double precision[], double precision
pg_catalog | float8_avg | double
precision | double precision[]
pg_catalog | float8_corr | double
precision | double precision[]
pg_catalog | float8_covar_pop | double
precision | double precision[]
pg_catalog | float8_covar_samp | double
precision | double precision[]
pg_catalog | float8_regr_accum | double
precision[] | double precision[], double precision, double
precision
pg_catalog | float8_regr_avgx | double
precision | double precision[]
pg_catalog | float8_regr_avgy | double
precision | double precision[]
pg_catalog | float8_regr_intercept | double
precision | double precision[]
pg_catalog | float8_regr_r2 | double
precision | double precision[]
pg_catalog | float8_regr_slope | double
precision | double precision[]
pg_catalog | float8_regr_sxx | double
precision | double precision[]
pg_catalog | float8_regr_sxy | double
precision | double precision[]
pg_catalog | float8_regr_syy | double
precision | double precision[]
pg_catalog | float8_stddev_pop | double
precision | double precision[]
pg_catalog | float8_stddev_samp | double
precision | double precision[]
pg_catalog | float8_var_pop | double
precision | double precision[]
pg_catalog | float8_var_samp | double
precision | double precision[]
pg_catalog | float8abs | double
precision | double precision
pg_catalog | float8div | double
precision | double precision, double precision
pg_catalog | float8eq | boolean
| double precision, double precision
pg_catalog | float8ge | boolean
| double precision, double precision
pg_catalog | float8gt | boolean
| double precision, double precision
pg_catalog | float8larger | double
precision | double precision, double precision
pg_catalog | float8le | boolean
| double precision, double precision
pg_catalog | float8lt | boolean
| double precision, double precision
pg_catalog | float8mi | double
precision | double precision, double precision
pg_catalog | float8mul | double
precision | double precision, double precision
pg_catalog | float8ne | boolean
| double precision, double precision
pg_catalog | float8pl | double
precision | double precision, double precision
pg_catalog | float8recv | double
precision | internal
pg_catalog | float8send | bytea
| double precision
pg_catalog | float8smaller | double
precision | double precision, double precision
pg_catalog | float8um | double
precision | double precision
pg_catalog | float8up | double
precision | double precision
pg_catalog | floor | double
precision | double precision
pg_catalog | floor | numeric
| numeric
pg_catalog | flt4_mul_cash | money
| real, money
pg_catalog | flt8_mul_cash | money
| double precision, money
pg_catalog | fmgr_c_validator | void
| oid
pg_catalog | fmgr_internal_validator | void
| oid
pg_catalog | fmgr_sql_validator | void
| oid
pg_catalog | format_type | text
| oid, integer
pg_catalog | gb18030_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | gbk_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | generate_series | setof
bigint | bigint, bigint
pg_catalog | generate_series | setof
bigint | bigint, bigint, bigint
pg_catalog | generate_series | setof
integer | integer, integer
pg_catalog | generate_series | setof
integer | integer, integer, integer
pg_catalog | get_bit | integer
| bytea, integer
pg_catalog | get_byte | integer
| bytea, integer
pg_catalog | get_current_ts_config | regconfig
|
pg_catalog | getdatabaseencoding | name
|
pg_catalog | getpgusername | name
|
pg_catalog | gin_extract_tsquery | internal
| tsquery, internal, smallint
pg_catalog | gin_extract_tsvector | internal
| tsvector, internal
pg_catalog | gin_tsquery_consistent | boolean
| internal, smallint, tsquery
pg_catalog | ginarrayconsistent | boolean
| internal, smallint, internal
pg_catalog | ginarrayextract | internal
| anyarray, internal
pg_catalog | ginbeginscan | internal
| internal, internal, internal
pg_catalog | ginbuild | internal
| internal, internal, internal
pg_catalog | ginbulkdelete | internal
| internal, internal, internal, internal
pg_catalog | gincostestimate | void
| internal, internal, internal, internal, internal, internal, internal,
internal
pg_catalog | ginendscan | void
| internal
pg_catalog | gingetmulti | boolean
| internal, internal, internal, internal
pg_catalog | gingettuple | boolean
| internal, internal
pg_catalog | gininsert | boolean
| internal, internal, internal, internal, internal, internal
pg_catalog | ginmarkpos | void
| internal
pg_catalog | ginoptions | bytea
| text[], boolean
pg_catalog | ginqueryarrayextract | internal
| anyarray, internal, smallint
pg_catalog | ginrescan | void
| internal, internal
pg_catalog | ginrestrpos | void
| internal
pg_catalog | ginvacuumcleanup | internal
| internal, internal
pg_catalog | gist_box_compress | internal
| internal
pg_catalog | gist_box_consistent | boolean
| internal, box, integer
pg_catalog | gist_box_decompress | internal
| internal
pg_catalog | gist_box_penalty | internal
| internal, internal, internal
pg_catalog | gist_box_picksplit | internal
| internal, internal
pg_catalog | gist_box_same | internal
| box, box, internal
pg_catalog | gist_box_union | box
| internal, internal
pg_catalog | gist_circle_compress | internal
| internal
pg_catalog | gist_circle_consistent | boolean
| internal, circle, integer
pg_catalog | gist_poly_compress | internal
| internal
pg_catalog | gist_poly_consistent | boolean
| internal, polygon, integer
pg_catalog | gistbeginscan | internal
| internal, internal, internal
pg_catalog | gistbuild | internal
| internal, internal, internal
pg_catalog | gistbulkdelete | internal
| internal, internal, internal, internal
pg_catalog | gistcostestimate | void
| internal, internal, internal, internal, internal, internal, internal,
internal
pg_catalog | gistendscan | void
| internal
pg_catalog | gistgetmulti | boolean
| internal, internal, internal, internal
pg_catalog | gistgettuple | boolean
| internal, internal
pg_catalog | gistinsert | boolean
| internal, internal, internal, internal, internal, internal
pg_catalog | gistmarkpos | void
| internal
pg_catalog | gistoptions | bytea
| text[], boolean
pg_catalog | gistrescan | void
| internal, internal
pg_catalog | gistrestrpos | void
| internal
pg_catalog | gistvacuumcleanup | internal
| internal, internal
pg_catalog | gtsquery_compress | internal
| internal
pg_catalog | gtsquery_consistent | boolean
| bigint, internal, integer
pg_catalog | gtsquery_decompress | internal
| internal
pg_catalog | gtsquery_penalty | internal
| internal, internal, internal
pg_catalog | gtsquery_picksplit | internal
| internal, internal
pg_catalog | gtsquery_same | internal
| bigint, bigint, internal
pg_catalog | gtsquery_union | internal
| internal, internal
pg_catalog | gtsvector_compress | internal
| internal
pg_catalog | gtsvector_consistent | boolean
| gtsvector, internal, integer
pg_catalog | gtsvector_decompress | internal
| internal
pg_catalog | gtsvector_penalty | internal
| internal, internal, internal
pg_catalog | gtsvector_picksplit | internal
| internal, internal
pg_catalog | gtsvector_same | internal
| gtsvector, gtsvector, internal
pg_catalog | gtsvector_union | internal
| internal, internal
pg_catalog | has_database_privilege | boolean
| name, oid, text
pg_catalog | has_database_privilege | boolean
| name, text, text
pg_catalog | has_database_privilege | boolean
| oid, oid, text
pg_catalog | has_database_privilege | boolean
| oid, text
pg_catalog | has_database_privilege | boolean
| oid, text, text
pg_catalog | has_database_privilege | boolean
| text, text
pg_catalog | has_function_privilege | boolean
| name, oid, text
pg_catalog | has_function_privilege | boolean
| name, text, text
pg_catalog | has_function_privilege | boolean
| oid, oid, text
pg_catalog | has_function_privilege | boolean
| oid, text
pg_catalog | has_function_privilege | boolean
| oid, text, text
pg_catalog | has_function_privilege | boolean
| text, text
pg_catalog | has_language_privilege | boolean
| name, oid, text
pg_catalog | has_language_privilege | boolean
| name, text, text
pg_catalog | has_language_privilege | boolean
| oid, oid, text
pg_catalog | has_language_privilege | boolean
| oid, text
pg_catalog | has_language_privilege | boolean
| oid, text, text
pg_catalog | has_language_privilege | boolean
| text, text
pg_catalog | has_schema_privilege | boolean
| name, oid, text
pg_catalog | has_schema_privilege | boolean
| name, text, text
pg_catalog | has_schema_privilege | boolean
| oid, oid, text
pg_catalog | has_schema_privilege | boolean
| oid, text
pg_catalog | has_schema_privilege | boolean
| oid, text, text
pg_catalog | has_schema_privilege | boolean
| text, text
pg_catalog | has_table_privilege | boolean
| name, oid, text
pg_catalog | has_table_privilege | boolean
| name, text, text
pg_catalog | has_table_privilege | boolean
| oid, oid, text
pg_catalog | has_table_privilege | boolean
| oid, text
pg_catalog | has_table_privilege | boolean
| oid, text, text
pg_catalog | has_table_privilege | boolean
| text, text
pg_catalog | has_tablespace_privilege | boolean
| name, oid, text
pg_catalog | has_tablespace_privilege | boolean
| name, text, text
pg_catalog | has_tablespace_privilege | boolean
| oid, oid, text
pg_catalog | has_tablespace_privilege | boolean
| oid, text
pg_catalog | has_tablespace_privilege | boolean
| oid, text, text
pg_catalog | has_tablespace_privilege | boolean
| text, text
pg_catalog | hash_aclitem | integer
| aclitem
pg_catalog | hash_numeric | integer
| numeric
pg_catalog | hashbeginscan | internal
| internal, internal, internal
pg_catalog | hashbpchar | integer
| character
pg_catalog | hashbuild | internal
| internal, internal, internal
pg_catalog | hashbulkdelete | internal
| internal, internal, internal, internal
pg_catalog | hashchar | integer
| "char"
pg_catalog | hashcostestimate | void
| internal, internal, internal, internal, internal, internal, internal,
internal
pg_catalog | hashendscan | void
| internal
pg_catalog | hashenum | integer
| anyenum
pg_catalog | hashfloat4 | integer
| real
pg_catalog | hashfloat8 | integer
| double precision
pg_catalog | hashgetmulti | boolean
| internal, internal, internal, internal
pg_catalog | hashgettuple | boolean
| internal, internal
pg_catalog | hashinet | integer
| inet
pg_catalog | hashinsert | boolean
| internal, internal, internal, internal, internal, internal
pg_catalog | hashint2 | integer
| smallint
pg_catalog | hashint2vector | integer
| int2vector
pg_catalog | hashint4 | integer
| integer
pg_catalog | hashint8 | integer
| bigint
pg_catalog | hashmacaddr | integer
| macaddr
pg_catalog | hashmarkpos | void
| internal
pg_catalog | hashname | integer
| name
pg_catalog | hashoid | integer
| oid
pg_catalog | hashoidvector | integer
| oidvector
pg_catalog | hashoptions | bytea
| text[], boolean
pg_catalog | hashrescan | void
| internal, internal
pg_catalog | hashrestrpos | void
| internal
pg_catalog | hashtext | integer
| text
pg_catalog | hashvacuumcleanup | internal
| internal, internal
pg_catalog | hashvarlena | integer
| internal
pg_catalog | height | double
precision | box
pg_catalog | host | text
| inet
pg_catalog | hostmask | inet
| inet
pg_catalog | iclikejoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | iclikesel | double
precision | internal, oid, internal, integer
pg_catalog | icnlikejoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | icnlikesel | double
precision | internal, oid, internal, integer
pg_catalog | icregexeqjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | icregexeqsel | double
precision | internal, oid, internal, integer
pg_catalog | icregexnejoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | icregexnesel | double
precision | internal, oid, internal, integer
pg_catalog | inet_client_addr | inet
|
pg_catalog | inet_client_port | integer
|
pg_catalog | inet_recv | inet
| internal
pg_catalog | inet_send | bytea
| inet
pg_catalog | inet_server_addr | inet
|
pg_catalog | inet_server_port | integer
|
pg_catalog | inetand | inet
| inet, inet
pg_catalog | inetmi | bigint
| inet, inet
pg_catalog | inetmi_int8 | inet
| inet, bigint
pg_catalog | inetnot | inet
| inet
pg_catalog | inetor | inet
| inet, inet
pg_catalog | inetpl | inet
| inet, bigint
pg_catalog | initcap | text
| text
pg_catalog | int2 | smallint
| bigint
pg_catalog | int2 | smallint
| double precision
pg_catalog | int2 | smallint
| integer
pg_catalog | int2 | smallint
| numeric
pg_catalog | int2 | smallint
| real
pg_catalog | int24div | integer
| smallint, integer
pg_catalog | int24eq | boolean
| smallint, integer
pg_catalog | int24ge | boolean
| smallint, integer
pg_catalog | int24gt | boolean
| smallint, integer
pg_catalog | int24le | boolean
| smallint, integer
pg_catalog | int24lt | boolean
| smallint, integer
pg_catalog | int24mi | integer
| smallint, integer
pg_catalog | int24mod | integer
| smallint, integer
pg_catalog | int24mul | integer
| smallint, integer
pg_catalog | int24ne | boolean
| smallint, integer
pg_catalog | int24pl | integer
| smallint, integer
pg_catalog | int28eq | boolean
| smallint, bigint
pg_catalog | int28ge | boolean
| smallint, bigint
pg_catalog | int28gt | boolean
| smallint, bigint
pg_catalog | int28le | boolean
| smallint, bigint
pg_catalog | int28lt | boolean
| smallint, bigint
pg_catalog | int28ne | boolean
| smallint, bigint
pg_catalog | int2_accum | numeric[]
| numeric[], smallint
pg_catalog | int2_avg_accum | bigint[]
| bigint[], smallint
pg_catalog | int2_mul_cash | money
| smallint, money
pg_catalog | int2_sum | bigint
| bigint, smallint
pg_catalog | int2abs | smallint
| smallint
pg_catalog | int2and | smallint
| smallint, smallint
pg_catalog | int2div | smallint
| smallint, smallint
pg_catalog | int2eq | boolean
| smallint, smallint
pg_catalog | int2ge | boolean
| smallint, smallint
pg_catalog | int2gt | boolean
| smallint, smallint
pg_catalog | int2larger | smallint
| smallint, smallint
pg_catalog | int2le | boolean
| smallint, smallint
pg_catalog | int2lt | boolean
| smallint, smallint
pg_catalog | int2mi | smallint
| smallint, smallint
pg_catalog | int2mod | smallint
| smallint, smallint
pg_catalog | int2mul | smallint
| smallint, smallint
pg_catalog | int2ne | boolean
| smallint, smallint
pg_catalog | int2not | smallint
| smallint
pg_catalog | int2or | smallint
| smallint, smallint
pg_catalog | int2pl | smallint
| smallint, smallint
pg_catalog | int2recv | smallint
| internal
pg_catalog | int2send | bytea
| smallint
pg_catalog | int2shl | smallint
| smallint, integer
pg_catalog | int2shr | smallint
| smallint, integer
pg_catalog | int2smaller | smallint
| smallint, smallint
pg_catalog | int2um | smallint
| smallint
pg_catalog | int2up | smallint
| smallint
pg_catalog | int2vectoreq | boolean
| int2vector, int2vector
pg_catalog | int2vectorrecv | int2vector
| internal
pg_catalog | int2vectorsend | bytea
| int2vector
pg_catalog | int2xor | smallint
| smallint, smallint
pg_catalog | int4 | integer
| bigint
pg_catalog | int4 | integer
| bit
pg_catalog | int4 | integer
| boolean
pg_catalog | int4 | integer
| "char"
pg_catalog | int4 | integer
| double precision
pg_catalog | int4 | integer
| numeric
pg_catalog | int4 | integer
| real
pg_catalog | int4 | integer
| smallint
pg_catalog | int42div | integer
| integer, smallint
pg_catalog | int42eq | boolean
| integer, smallint
pg_catalog | int42ge | boolean
| integer, smallint
pg_catalog | int42gt | boolean
| integer, smallint
pg_catalog | int42le | boolean
| integer, smallint
pg_catalog | int42lt | boolean
| integer, smallint
pg_catalog | int42mi | integer
| integer, smallint
pg_catalog | int42mod | integer
| integer, smallint
pg_catalog | int42mul | integer
| integer, smallint
pg_catalog | int42ne | boolean
| integer, smallint
pg_catalog | int42pl | integer
| integer, smallint
pg_catalog | int48div | bigint
| integer, bigint
pg_catalog | int48eq | boolean
| integer, bigint
pg_catalog | int48ge | boolean
| integer, bigint
pg_catalog | int48gt | boolean
| integer, bigint
pg_catalog | int48le | boolean
| integer, bigint
pg_catalog | int48lt | boolean
| integer, bigint
pg_catalog | int48mi | bigint
| integer, bigint
pg_catalog | int48mul | bigint
| integer, bigint
pg_catalog | int48ne | boolean
| integer, bigint
pg_catalog | int48pl | bigint
| integer, bigint
pg_catalog | int4_accum | numeric[]
| numeric[], integer
pg_catalog | int4_avg_accum | bigint[]
| bigint[], integer
pg_catalog | int4_mul_cash | money
| integer, money
pg_catalog | int4_sum | bigint
| bigint, integer
pg_catalog | int4abs | integer
| integer
pg_catalog | int4and | integer
| integer, integer
pg_catalog | int4div | integer
| integer, integer
pg_catalog | int4eq | boolean
| integer, integer
pg_catalog | int4ge | boolean
| integer, integer
pg_catalog | int4gt | boolean
| integer, integer
pg_catalog | int4inc | integer
| integer
pg_catalog | int4larger | integer
| integer, integer
pg_catalog | int4le | boolean
| integer, integer
pg_catalog | int4lt | boolean
| integer, integer
pg_catalog | int4mi | integer
| integer, integer
pg_catalog | int4mod | integer
| integer, integer
pg_catalog | int4mul | integer
| integer, integer
pg_catalog | int4ne | boolean
| integer, integer
pg_catalog | int4not | integer
| integer
pg_catalog | int4or | integer
| integer, integer
pg_catalog | int4pl | integer
| integer, integer
pg_catalog | int4recv | integer
| internal
pg_catalog | int4send | bytea
| integer
pg_catalog | int4shl | integer
| integer, integer
pg_catalog | int4shr | integer
| integer, integer
pg_catalog | int4smaller | integer
| integer, integer
pg_catalog | int4um | integer
| integer
pg_catalog | int4up | integer
| integer
pg_catalog | int4xor | integer
| integer, integer
pg_catalog | int8 | bigint
| bit
pg_catalog | int8 | bigint
| double precision
pg_catalog | int8 | bigint
| integer
pg_catalog | int8 | bigint
| numeric
pg_catalog | int8 | bigint
| oid
pg_catalog | int8 | bigint
| real
pg_catalog | int8 | bigint
| smallint
pg_catalog | int82eq | boolean
| bigint, smallint
pg_catalog | int82ge | boolean
| bigint, smallint
pg_catalog | int82gt | boolean
| bigint, smallint
pg_catalog | int82le | boolean
| bigint, smallint
pg_catalog | int82lt | boolean
| bigint, smallint
pg_catalog | int82ne | boolean
| bigint, smallint
pg_catalog | int84div | bigint
| bigint, integer
pg_catalog | int84eq | boolean
| bigint, integer
pg_catalog | int84ge | boolean
| bigint, integer
pg_catalog | int84gt | boolean
| bigint, integer
pg_catalog | int84le | boolean
| bigint, integer
pg_catalog | int84lt | boolean
| bigint, integer
pg_catalog | int84mi | bigint
| bigint, integer
pg_catalog | int84mul | bigint
| bigint, integer
pg_catalog | int84ne | boolean
| bigint, integer
pg_catalog | int84pl | bigint
| bigint, integer
pg_catalog | int8_accum | numeric[]
| numeric[], bigint
pg_catalog | int8_avg | numeric
| bigint[]
pg_catalog | int8_avg_accum | numeric[]
| numeric[], bigint
pg_catalog | int8_sum | numeric
| numeric, bigint
pg_catalog | int8abs | bigint
| bigint
pg_catalog | int8and | bigint
| bigint, bigint
pg_catalog | int8div | bigint
| bigint, bigint
pg_catalog | int8eq | boolean
| bigint, bigint
pg_catalog | int8ge | boolean
| bigint, bigint
pg_catalog | int8gt | boolean
| bigint, bigint
pg_catalog | int8inc | bigint
| bigint
pg_catalog | int8inc_any | bigint
| bigint, "any"
pg_catalog | int8inc_float8_float8 | bigint
| bigint, double precision, double precision
pg_catalog | int8larger | bigint
| bigint, bigint
pg_catalog | int8le | boolean
| bigint, bigint
pg_catalog | int8lt | boolean
| bigint, bigint
pg_catalog | int8mi | bigint
| bigint, bigint
pg_catalog | int8mod | bigint
| bigint, bigint
pg_catalog | int8mul | bigint
| bigint, bigint
pg_catalog | int8ne | boolean
| bigint, bigint
pg_catalog | int8not | bigint
| bigint
pg_catalog | int8or | bigint
| bigint, bigint
pg_catalog | int8pl | bigint
| bigint, bigint
pg_catalog | int8pl_inet | inet
| bigint, inet
pg_catalog | int8recv | bigint
| internal
pg_catalog | int8send | bytea
| bigint
pg_catalog | int8shl | bigint
| bigint, integer
pg_catalog | int8shr | bigint
| bigint, integer
pg_catalog | int8smaller | bigint
| bigint, bigint
pg_catalog | int8um | bigint
| bigint
pg_catalog | int8up | bigint
| bigint
pg_catalog | int8xor | bigint
| bigint, bigint
pg_catalog | integer_pl_date | date
| integer, date
pg_catalog | inter_lb | boolean
| line, box
pg_catalog | inter_sb | boolean
| lseg, box
pg_catalog | inter_sl | boolean
| lseg, line
pg_catalog | interval | interval
| interval, integer
pg_catalog | interval | interval
| reltime
pg_catalog | interval | interval
| time without time zone
pg_catalog | interval_accum | interval[]
| interval[], interval
pg_catalog | interval_avg | interval
| interval[]
pg_catalog | interval_cmp | integer
| interval, interval
pg_catalog | interval_div | interval
| interval, double precision
pg_catalog | interval_eq | boolean
| interval, interval
pg_catalog | interval_ge | boolean
| interval, interval
pg_catalog | interval_gt | boolean
| interval, interval
pg_catalog | interval_hash | integer
| interval
pg_catalog | interval_larger | interval
| interval, interval
pg_catalog | interval_le | boolean
| interval, interval
pg_catalog | interval_lt | boolean
| interval, interval
pg_catalog | interval_mi | interval
| interval, interval
pg_catalog | interval_mul | interval
| interval, double precision
pg_catalog | interval_ne | boolean
| interval, interval
pg_catalog | interval_pl | interval
| interval, interval
pg_catalog | interval_pl_date | timestamp
without time zone | interval, date
pg_catalog | interval_pl_time | time
without time zone | interval, time without time zone
pg_catalog | interval_pl_timestamp | timestamp
without time zone | interval, timestamp without time zone
pg_catalog | interval_pl_timestamptz | timestamp
with time zone | interval, timestamp with time zone
pg_catalog | interval_pl_timetz | time with
time zone | interval, time with time zone
pg_catalog | interval_recv | interval
| internal, oid, integer
pg_catalog | interval_send | bytea
| interval
pg_catalog | interval_smaller | interval
| interval, interval
pg_catalog | interval_um | interval
| interval
pg_catalog | intervaltypmodin | integer
| cstring[]
pg_catalog | intinterval | boolean
| abstime, tinterval
pg_catalog | isclosed | boolean
| path
pg_catalog | isfalse | boolean
| boolean
pg_catalog | isfinite | boolean
| abstime
pg_catalog | isfinite | boolean
| interval
pg_catalog | isfinite | boolean
| timestamp without time zone
pg_catalog | isfinite | boolean
| timestamp with time zone
pg_catalog | ishorizontal | boolean
| line
pg_catalog | ishorizontal | boolean
| lseg
pg_catalog | ishorizontal | boolean
| point, point
pg_catalog | isnotfalse | boolean
| boolean
pg_catalog | isnottrue | boolean
| boolean
pg_catalog | iso8859_1_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | iso8859_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | iso_to_koi8r | void
| integer, integer, cstring, internal, integer
pg_catalog | iso_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | iso_to_win1251 | void
| integer, integer, cstring, internal, integer
pg_catalog | iso_to_win866 | void
| integer, integer, cstring, internal, integer
pg_catalog | isopen | boolean
| path
pg_catalog | isparallel | boolean
| line, line
pg_catalog | isparallel | boolean
| lseg, lseg
pg_catalog | isperp | boolean
| line, line
pg_catalog | isperp | boolean
| lseg, lseg
pg_catalog | istrue | boolean
| boolean
pg_catalog | isvertical | boolean
| line
pg_catalog | isvertical | boolean
| lseg
pg_catalog | isvertical | boolean
| point, point
pg_catalog | johab_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | justify_days | interval
| interval
pg_catalog | justify_hours | interval
| interval
pg_catalog | justify_interval | interval
| interval
pg_catalog | koi8r_to_iso | void
| integer, integer, cstring, internal, integer
pg_catalog | koi8r_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | koi8r_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | koi8r_to_win1251 | void
| integer, integer, cstring, internal, integer
pg_catalog | koi8r_to_win866 | void
| integer, integer, cstring, internal, integer
pg_catalog | lastval | bigint
|
pg_catalog | latin1_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | latin2_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | latin2_to_win1250 | void
| integer, integer, cstring, internal, integer
pg_catalog | latin3_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | latin4_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | length | double
precision | lseg
pg_catalog | length | double
precision | path
pg_catalog | length | integer
| bit
pg_catalog | length | integer
| bytea
pg_catalog | length | integer
| bytea, name
pg_catalog | length | integer
| character
pg_catalog | length | integer
| text
pg_catalog | length | integer
| tsvector
pg_catalog | like | boolean
| bytea, bytea
pg_catalog | like | boolean
| name, text
pg_catalog | like | boolean
| text, text
pg_catalog | like_escape | bytea
| bytea, bytea
pg_catalog | like_escape | text
| text, text
pg_catalog | likejoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | likesel | double
precision | internal, oid, internal, integer
pg_catalog | line | line
| point, point
pg_catalog | line_distance | double
precision | line, line
pg_catalog | line_eq | boolean
| line, line
pg_catalog | line_horizontal | boolean
| line
pg_catalog | line_interpt | point
| line, line
pg_catalog | line_intersect | boolean
| line, line
pg_catalog | line_parallel | boolean
| line, line
pg_catalog | line_perp | boolean
| line, line
pg_catalog | line_recv | line
| internal
pg_catalog | line_send | bytea
| line
pg_catalog | line_vertical | boolean
| line
pg_catalog | ln | double
precision | double precision
pg_catalog | ln | numeric
| numeric
pg_catalog | lo_close | integer
| integer
pg_catalog | lo_creat | oid
| integer
pg_catalog | lo_create | oid
| oid
pg_catalog | lo_export | integer
| oid, text
pg_catalog | lo_import | oid
| text
pg_catalog | lo_lseek | integer
| integer, integer, integer
pg_catalog | lo_open | integer
| oid, integer
pg_catalog | lo_tell | integer
| integer
pg_catalog | lo_truncate | integer
| integer, integer
pg_catalog | lo_unlink | integer
| oid
pg_catalog | log | double
precision | double precision
pg_catalog | log | numeric
| numeric
pg_catalog | log | numeric
| numeric, numeric
pg_catalog | loread | bytea
| integer, integer
pg_catalog | lower | text
| text
pg_catalog | lowrite | integer
| integer, bytea
pg_catalog | lpad | text
| text, integer
pg_catalog | lpad | text
| text, integer, text
pg_catalog | lseg | lseg
| box
pg_catalog | lseg | lseg
| point, point
pg_catalog | lseg_center | point
| lseg
pg_catalog | lseg_distance | double
precision | lseg, lseg
pg_catalog | lseg_eq | boolean
| lseg, lseg
pg_catalog | lseg_ge | boolean
| lseg, lseg
pg_catalog | lseg_gt | boolean
| lseg, lseg
pg_catalog | lseg_horizontal | boolean
| lseg
pg_catalog | lseg_interpt | point
| lseg, lseg
pg_catalog | lseg_intersect | boolean
| lseg, lseg
pg_catalog | lseg_le | boolean
| lseg, lseg
pg_catalog | lseg_length | double
precision | lseg
pg_catalog | lseg_lt | boolean
| lseg, lseg
pg_catalog | lseg_ne | boolean
| lseg, lseg
pg_catalog | lseg_parallel | boolean
| lseg, lseg
pg_catalog | lseg_perp | boolean
| lseg, lseg
pg_catalog | lseg_recv | lseg
| internal
pg_catalog | lseg_send | bytea
| lseg
pg_catalog | lseg_vertical | boolean
| lseg
pg_catalog | ltrim | text
| text
pg_catalog | ltrim | text
| text, text
pg_catalog | macaddr_cmp | integer
| macaddr, macaddr
pg_catalog | macaddr_eq | boolean
| macaddr, macaddr
pg_catalog | macaddr_ge | boolean
| macaddr, macaddr
pg_catalog | macaddr_gt | boolean
| macaddr, macaddr
pg_catalog | macaddr_le | boolean
| macaddr, macaddr
pg_catalog | macaddr_lt | boolean
| macaddr, macaddr
pg_catalog | macaddr_ne | boolean
| macaddr, macaddr
pg_catalog | macaddr_recv | macaddr
| internal
pg_catalog | macaddr_send | bytea
| macaddr
pg_catalog | makeaclitem | aclitem
| oid, oid, text, boolean
pg_catalog | masklen | integer
| inet
pg_catalog | md5 | text
| bytea
pg_catalog | md5 | text
| text
pg_catalog | mic_to_ascii | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_big5 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_euc_cn | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_euc_jp | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_euc_kr | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_euc_tw | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_iso | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_koi8r | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_latin1 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_latin2 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_latin3 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_latin4 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_sjis | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_win1250 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_win1251 | void
| integer, integer, cstring, internal, integer
pg_catalog | mic_to_win866 | void
| integer, integer, cstring, internal, integer
pg_catalog | mktinterval | tinterval
| abstime, abstime
pg_catalog | mod | bigint
| bigint, bigint
pg_catalog | mod | integer
| integer, integer
pg_catalog | mod | integer
| integer, smallint
pg_catalog | mod | integer
| smallint, integer
pg_catalog | mod | numeric
| numeric, numeric
pg_catalog | mod | smallint
| smallint, smallint
pg_catalog | mul_d_interval | interval
| double precision, interval
pg_catalog | name | name
| character
pg_catalog | name | name
| character varying
pg_catalog | name | name
| text
pg_catalog | name_pattern_eq | boolean
| name, name
pg_catalog | name_pattern_ge | boolean
| name, name
pg_catalog | name_pattern_gt | boolean
| name, name
pg_catalog | name_pattern_le | boolean
| name, name
pg_catalog | name_pattern_lt | boolean
| name, name
pg_catalog | name_pattern_ne | boolean
| name, name
pg_catalog | nameeq | boolean
| name, name
pg_catalog | namege | boolean
| name, name
pg_catalog | namegt | boolean
| name, name
pg_catalog | nameiclike | boolean
| name, text
pg_catalog | nameicnlike | boolean
| name, text
pg_catalog | nameicregexeq | boolean
| name, text
pg_catalog | nameicregexne | boolean
| name, text
pg_catalog | namele | boolean
| name, name
pg_catalog | namelike | boolean
| name, text
pg_catalog | namelt | boolean
| name, name
pg_catalog | namene | boolean
| name, name
pg_catalog | namenlike | boolean
| name, text
pg_catalog | namerecv | name
| internal
pg_catalog | nameregexeq | boolean
| name, text
pg_catalog | nameregexne | boolean
| name, text
pg_catalog | namesend | bytea
| name
pg_catalog | neqjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | neqsel | double
precision | internal, oid, internal, integer
pg_catalog | netmask | inet
| inet
pg_catalog | network | cidr
| inet
pg_catalog | network_cmp | integer
| inet, inet
pg_catalog | network_eq | boolean
| inet, inet
pg_catalog | network_ge | boolean
| inet, inet
pg_catalog | network_gt | boolean
| inet, inet
pg_catalog | network_le | boolean
| inet, inet
pg_catalog | network_lt | boolean
| inet, inet
pg_catalog | network_ne | boolean
| inet, inet
pg_catalog | network_sub | boolean
| inet, inet
pg_catalog | network_subeq | boolean
| inet, inet
pg_catalog | network_sup | boolean
| inet, inet
pg_catalog | network_supeq | boolean
| inet, inet
pg_catalog | nextval | bigint
| regclass
pg_catalog | nlikejoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | nlikesel | double
precision | internal, oid, internal, integer
pg_catalog | nonnullvalue | boolean
| "any"
pg_catalog | notlike | boolean
| bytea, bytea
pg_catalog | notlike | boolean
| name, text
pg_catalog | notlike | boolean
| text, text
pg_catalog | now | timestamp
with time zone |
pg_catalog | npoints | integer
| path
pg_catalog | npoints | integer
| polygon
pg_catalog | nullvalue | boolean
| "any"
pg_catalog | numeric | numeric
| bigint
pg_catalog | numeric | numeric
| double precision
pg_catalog | numeric | numeric
| integer
pg_catalog | numeric | numeric
| numeric, integer
pg_catalog | numeric | numeric
| real
pg_catalog | numeric | numeric
| smallint
pg_catalog | numeric_abs | numeric
| numeric
pg_catalog | numeric_accum | numeric[]
| numeric[], numeric
pg_catalog | numeric_add | numeric
| numeric, numeric
pg_catalog | numeric_avg | numeric
| numeric[]
pg_catalog | numeric_avg_accum | numeric[]
| numeric[], numeric
pg_catalog | numeric_cmp | integer
| numeric, numeric
pg_catalog | numeric_div | numeric
| numeric, numeric
pg_catalog | numeric_eq | boolean
| numeric, numeric
pg_catalog | numeric_exp | numeric
| numeric
pg_catalog | numeric_fac | numeric
| bigint
pg_catalog | numeric_ge | boolean
| numeric, numeric
pg_catalog | numeric_gt | boolean
| numeric, numeric
pg_catalog | numeric_inc | numeric
| numeric
pg_catalog | numeric_larger | numeric
| numeric, numeric
pg_catalog | numeric_le | boolean
| numeric, numeric
pg_catalog | numeric_ln | numeric
| numeric
pg_catalog | numeric_log | numeric
| numeric, numeric
pg_catalog | numeric_lt | boolean
| numeric, numeric
pg_catalog | numeric_mod | numeric
| numeric, numeric
pg_catalog | numeric_mul | numeric
| numeric, numeric
pg_catalog | numeric_ne | boolean
| numeric, numeric
pg_catalog | numeric_power | numeric
| numeric, numeric
pg_catalog | numeric_recv | numeric
| internal, oid, integer
pg_catalog | numeric_send | bytea
| numeric
pg_catalog | numeric_smaller | numeric
| numeric, numeric
pg_catalog | numeric_sqrt | numeric
| numeric
pg_catalog | numeric_stddev_pop | numeric
| numeric[]
pg_catalog | numeric_stddev_samp | numeric
| numeric[]
pg_catalog | numeric_sub | numeric
| numeric, numeric
pg_catalog | numeric_uminus | numeric
| numeric
pg_catalog | numeric_uplus | numeric
| numeric
pg_catalog | numeric_var_pop | numeric
| numeric[]
pg_catalog | numeric_var_samp | numeric
| numeric[]
pg_catalog | numerictypmodin | integer
| cstring[]
pg_catalog | numnode | integer
| tsquery
pg_catalog | obj_description | text
| oid
pg_catalog | obj_description | text
| oid, name
pg_catalog | octet_length | integer
| bit
pg_catalog | octet_length | integer
| bytea
pg_catalog | octet_length | integer
| character
pg_catalog | octet_length | integer
| text
pg_catalog | oid | oid
| bigint
pg_catalog | oideq | boolean
| oid, oid
pg_catalog | oidge | boolean
| oid, oid
pg_catalog | oidgt | boolean
| oid, oid
pg_catalog | oidlarger | oid
| oid, oid
pg_catalog | oidle | boolean
| oid, oid
pg_catalog | oidlt | boolean
| oid, oid
pg_catalog | oidne | boolean
| oid, oid
pg_catalog | oidrecv | oid
| internal
pg_catalog | oidsend | bytea
| oid
pg_catalog | oidsmaller | oid
| oid, oid
pg_catalog | oidvectoreq | boolean
| oidvector, oidvector
pg_catalog | oidvectorge | boolean
| oidvector, oidvector
pg_catalog | oidvectorgt | boolean
| oidvector, oidvector
pg_catalog | oidvectorle | boolean
| oidvector, oidvector
pg_catalog | oidvectorlt | boolean
| oidvector, oidvector
pg_catalog | oidvectorne | boolean
| oidvector, oidvector
pg_catalog | oidvectorrecv | oidvector
| internal
pg_catalog | oidvectorsend | bytea
| oidvector
pg_catalog | oidvectortypes | text
| oidvector
pg_catalog | on_pb | boolean
| point, box
pg_catalog | on_pl | boolean
| point, line
pg_catalog | on_ppath | boolean
| point, path
pg_catalog | on_ps | boolean
| point, lseg
pg_catalog | on_sb | boolean
| lseg, box
pg_catalog | on_sl | boolean
| lseg, line
pg_catalog | overlaps | boolean
| timestamp without time zone, interval, timestamp without time zone,
interval
pg_catalog | overlaps | boolean
| timestamp without time zone, interval, timestamp without time zone,
timestamp without time zone
pg_catalog | overlaps | boolean
| timestamp without time zone, timestamp without time zone, timestamp
without time zone, interval
pg_catalog | overlaps | boolean
| timestamp without time zone, timestamp without time zone, timestamp
without time zone, timestamp without time zone
pg_catalog | overlaps | boolean
| timestamp with time zone, interval, timestamp with time zone, interval
pg_catalog | overlaps | boolean
| timestamp with time zone, interval, timestamp with time zone,
timestamp with time zone
pg_catalog | overlaps | boolean
| timestamp with time zone, timestamp with time zone, timestamp with
time zone, interval
pg_catalog | overlaps | boolean
| timestamp with time zone, timestamp with time zone, timestamp with
time zone, timestamp with time zone
pg_catalog | overlaps | boolean
| time without time zone, interval, time without time zone, interval
pg_catalog | overlaps | boolean
| time without time zone, interval, time without time zone, time without
time zone
pg_catalog | overlaps | boolean
| time without time zone, time without time zone, time without time
zone, interval
pg_catalog | overlaps | boolean
| time without time zone, time without time zone, time without time
zone, time without time zone
pg_catalog | overlaps | boolean
| time with time zone, time with time zone, time with time zone, time
with time zone
pg_catalog | overlay | text
| text, text, integer
pg_catalog | overlay | text
| text, text, integer, integer
pg_catalog | path | path
| polygon
pg_catalog | path_add | path
| path, path
pg_catalog | path_add_pt | path
| path, point
pg_catalog | path_center | point
| path
pg_catalog | path_contain_pt | boolean
| path, point
pg_catalog | path_distance | double
precision | path, path
pg_catalog | path_div_pt | path
| path, point
pg_catalog | path_inter | boolean
| path, path
pg_catalog | path_length | double
precision | path
pg_catalog | path_mul_pt | path
| path, point
pg_catalog | path_n_eq | boolean
| path, path
pg_catalog | path_n_ge | boolean
| path, path
pg_catalog | path_n_gt | boolean
| path, path
pg_catalog | path_n_le | boolean
| path, path
pg_catalog | path_n_lt | boolean
| path, path
pg_catalog | path_npoints | integer
| path
pg_catalog | path_recv | path
| internal
pg_catalog | path_send | bytea
| path
pg_catalog | path_sub_pt | path
| path, point
pg_catalog | pclose | path
| path
pg_catalog | pg_advisory_lock | void
| bigint
pg_catalog | pg_advisory_lock | void
| integer, integer
pg_catalog | pg_advisory_lock_shared | void
| bigint
pg_catalog | pg_advisory_lock_shared | void
| integer, integer
pg_catalog | pg_advisory_unlock | boolean
| bigint
pg_catalog | pg_advisory_unlock | boolean
| integer, integer
pg_catalog | pg_advisory_unlock_all | void
|
pg_catalog | pg_advisory_unlock_shared | boolean
| bigint
pg_catalog | pg_advisory_unlock_shared | boolean
| integer, integer
pg_catalog | pg_backend_pid | integer
|
pg_catalog | pg_cancel_backend | boolean
| integer
pg_catalog | pg_char_to_encoding | integer
| name
pg_catalog | pg_client_encoding | name
|
pg_catalog | pg_column_size | integer
| "any"
pg_catalog | pg_conversion_is_visible | boolean
| oid
pg_catalog | pg_current_xlog_insert_location | text
|
pg_catalog | pg_current_xlog_location | text
|
pg_catalog | pg_cursor | setof
record |
pg_catalog | pg_database_size | bigint
| name
pg_catalog | pg_database_size | bigint
| oid
pg_catalog | pg_encoding_to_char | name
| integer
pg_catalog | pg_function_is_visible | boolean
| oid
pg_catalog | pg_get_constraintdef | text
| oid
pg_catalog | pg_get_constraintdef | text
| oid, boolean
pg_catalog | pg_get_expr | text
| text, oid
pg_catalog | pg_get_expr | text
| text, oid, boolean
pg_catalog | pg_get_indexdef | text
| oid
pg_catalog | pg_get_indexdef | text
| oid, integer, boolean
pg_catalog | pg_get_ruledef | text
| oid
pg_catalog | pg_get_ruledef | text
| oid, boolean
pg_catalog | pg_get_serial_sequence | text
| text, text
pg_catalog | pg_get_triggerdef | text
| oid
pg_catalog | pg_get_userbyid | name
| oid
pg_catalog | pg_get_viewdef | text
| oid
pg_catalog | pg_get_viewdef | text
| oid, boolean
pg_catalog | pg_get_viewdef | text
| text
pg_catalog | pg_get_viewdef | text
| text, boolean
pg_catalog | pg_has_role | boolean
| name, name, text
pg_catalog | pg_has_role | boolean
| name, oid, text
pg_catalog | pg_has_role | boolean
| name, text
pg_catalog | pg_has_role | boolean
| oid, name, text
pg_catalog | pg_has_role | boolean
| oid, oid, text
pg_catalog | pg_has_role | boolean
| oid, text
pg_catalog | pg_is_other_temp_schema | boolean
| oid
pg_catalog | pg_lock_status | setof
record |
pg_catalog | pg_ls_dir | setof text
| text
pg_catalog | pg_my_temp_schema | oid
|
pg_catalog | pg_opclass_is_visible | boolean
| oid
pg_catalog | pg_operator_is_visible | boolean
| oid
pg_catalog | pg_postmaster_start_time | timestamp
with time zone |
pg_catalog | pg_prepared_statement | setof
record |
pg_catalog | pg_prepared_xact | setof
record |
pg_catalog | pg_read_file | text
| text, bigint, bigint
pg_catalog | pg_relation_size | bigint
| oid
pg_catalog | pg_relation_size | bigint
| text
pg_catalog | pg_reload_conf | boolean
|
pg_catalog | pg_rotate_logfile | boolean
|
pg_catalog | pg_show_all_settings | setof
record |
pg_catalog | pg_size_pretty | text
| bigint
pg_catalog | pg_sleep | void
| double precision
pg_catalog | pg_start_backup | text
| text
pg_catalog | pg_stat_clear_snapshot | void
|
pg_catalog | pg_stat_file | record
| filename text, OUT size bigint, OUT access timestamp with time zone,
OUT modification timestamp with time zone, OUT change timestamp with
time zone, OUT creation timestamp with time zone, OUT isdir boolean
pg_catalog | pg_stat_get_backend_activity | text
| integer
pg_catalog | pg_stat_get_backend_activity_start | timestamp
with time zone | integer
pg_catalog | pg_stat_get_backend_client_addr | inet
| integer
pg_catalog | pg_stat_get_backend_client_port | integer
| integer
pg_catalog | pg_stat_get_backend_dbid | oid
| integer
pg_catalog | pg_stat_get_backend_idset | setof
integer |
pg_catalog | pg_stat_get_backend_pid | integer
| integer
pg_catalog | pg_stat_get_backend_start | timestamp
with time zone | integer
pg_catalog | pg_stat_get_backend_userid | oid
| integer
pg_catalog | pg_stat_get_backend_waiting | boolean
| integer
pg_catalog | pg_stat_get_backend_xact_start | timestamp
with time zone | integer
pg_catalog | pg_stat_get_bgwriter_buf_written_checkpoints | bigint
|
pg_catalog | pg_stat_get_bgwriter_buf_written_clean | bigint
|
pg_catalog | pg_stat_get_bgwriter_maxwritten_clean | bigint
|
pg_catalog | pg_stat_get_bgwriter_requested_checkpoints | bigint
|
pg_catalog | pg_stat_get_bgwriter_timed_checkpoints | bigint
|
pg_catalog | pg_stat_get_blocks_fetched | bigint
| oid
pg_catalog | pg_stat_get_blocks_hit | bigint
| oid
pg_catalog | pg_stat_get_buf_alloc | bigint
|
pg_catalog | pg_stat_get_buf_written_backend | bigint
|
pg_catalog | pg_stat_get_db_blocks_fetched | bigint
| oid
pg_catalog | pg_stat_get_db_blocks_hit | bigint
| oid
pg_catalog | pg_stat_get_db_numbackends | integer
| oid
pg_catalog | pg_stat_get_db_tuples_deleted | bigint
| oid
pg_catalog | pg_stat_get_db_tuples_fetched | bigint
| oid
pg_catalog | pg_stat_get_db_tuples_inserted | bigint
| oid
pg_catalog | pg_stat_get_db_tuples_returned | bigint
| oid
pg_catalog | pg_stat_get_db_tuples_updated | bigint
| oid
pg_catalog | pg_stat_get_db_xact_commit | bigint
| oid
pg_catalog | pg_stat_get_db_xact_rollback | bigint
| oid
pg_catalog | pg_stat_get_dead_tuples | bigint
| oid
pg_catalog | pg_stat_get_last_analyze_time | timestamp
with time zone | oid
pg_catalog | pg_stat_get_last_autoanalyze_time | timestamp
with time zone | oid
pg_catalog | pg_stat_get_last_autovacuum_time | timestamp
with time zone | oid
pg_catalog | pg_stat_get_last_vacuum_time | timestamp
with time zone | oid
pg_catalog | pg_stat_get_live_tuples | bigint
| oid
pg_catalog | pg_stat_get_numscans | bigint
| oid
pg_catalog | pg_stat_get_tuples_deleted | bigint
| oid
pg_catalog | pg_stat_get_tuples_fetched | bigint
| oid
pg_catalog | pg_stat_get_tuples_hot_updated | bigint
| oid
pg_catalog | pg_stat_get_tuples_inserted | bigint
| oid
pg_catalog | pg_stat_get_tuples_returned | bigint
| oid
pg_catalog | pg_stat_get_tuples_updated | bigint
| oid
pg_catalog | pg_stat_reset | void
|
pg_catalog | pg_stop_backup | text
|
pg_catalog | pg_switch_xlog | text
|
pg_catalog | pg_table_is_visible | boolean
| oid
pg_catalog | pg_tablespace_databases | setof oid
| oid
pg_catalog | pg_tablespace_size | bigint
| name
pg_catalog | pg_tablespace_size | bigint
| oid
pg_catalog | pg_timezone_abbrevs | setof
record | OUT abbrev text, OUT utc_offset interval, OUT
is_dst boolean
pg_catalog | pg_timezone_names | setof
record | OUT name text, OUT abbrev text, OUT utc_offset
interval, OUT is_dst boolean
pg_catalog | pg_total_relation_size | bigint
| oid
pg_catalog | pg_total_relation_size | bigint
| text
pg_catalog | pg_try_advisory_lock | boolean
| bigint
pg_catalog | pg_try_advisory_lock | boolean
| integer, integer
pg_catalog | pg_try_advisory_lock_shared | boolean
| bigint
pg_catalog | pg_try_advisory_lock_shared | boolean
| integer, integer
pg_catalog | pg_ts_config_is_visible | boolean
| oid
pg_catalog | pg_ts_dict_is_visible | boolean
| oid
pg_catalog | pg_ts_parser_is_visible | boolean
| oid
pg_catalog | pg_ts_template_is_visible | boolean
| oid
pg_catalog | pg_type_is_visible | boolean
| oid
pg_catalog | pg_xlogfile_name | text
| text
pg_catalog | pg_xlogfile_name_offset | record
| wal_location text, OUT file_name text, OUT file_offset integer
pg_catalog | pi | double
precision |
pg_catalog | plainto_tsquery | tsquery
| regconfig, text
pg_catalog | plainto_tsquery | tsquery
| text
pg_catalog | plpgsql_call_handler |
language_handler |
pg_catalog | plpgsql_validator | void
| oid
pg_catalog | point | point
| box
pg_catalog | point | point
| circle
pg_catalog | point | point
| double precision, double precision
pg_catalog | point | point
| lseg
pg_catalog | point | point
| path
pg_catalog | point | point
| polygon
pg_catalog | point_above | boolean
| point, point
pg_catalog | point_add | point
| point, point
pg_catalog | point_below | boolean
| point, point
pg_catalog | point_distance | double
precision | point, point
pg_catalog | point_div | point
| point, point
pg_catalog | point_eq | boolean
| point, point
pg_catalog | point_horiz | boolean
| point, point
pg_catalog | point_left | boolean
| point, point
pg_catalog | point_mul | point
| point, point
pg_catalog | point_ne | boolean
| point, point
pg_catalog | point_recv | point
| internal
pg_catalog | point_right | boolean
| point, point
pg_catalog | point_send | bytea
| point
pg_catalog | point_sub | point
| point, point
pg_catalog | point_vert | boolean
| point, point
pg_catalog | poly_above | boolean
| polygon, polygon
pg_catalog | poly_below | boolean
| polygon, polygon
pg_catalog | poly_center | point
| polygon
pg_catalog | poly_contain | boolean
| polygon, polygon
pg_catalog | poly_contain_pt | boolean
| polygon, point
pg_catalog | poly_contained | boolean
| polygon, polygon
pg_catalog | poly_distance | double
precision | polygon, polygon
pg_catalog | poly_left | boolean
| polygon, polygon
pg_catalog | poly_npoints | integer
| polygon
pg_catalog | poly_overabove | boolean
| polygon, polygon
pg_catalog | poly_overbelow | boolean
| polygon, polygon
pg_catalog | poly_overlap | boolean
| polygon, polygon
pg_catalog | poly_overleft | boolean
| polygon, polygon
pg_catalog | poly_overright | boolean
| polygon, polygon
pg_catalog | poly_recv | polygon
| internal
pg_catalog | poly_right | boolean
| polygon, polygon
pg_catalog | poly_same | boolean
| polygon, polygon
pg_catalog | poly_send | bytea
| polygon
pg_catalog | polygon | polygon
| box
pg_catalog | polygon | polygon
| circle
pg_catalog | polygon | polygon
| integer, circle
pg_catalog | polygon | polygon
| path
pg_catalog | popen | path
| path
pg_catalog | position | integer
| bit, bit
pg_catalog | position | integer
| bytea, bytea
pg_catalog | position | integer
| text, text
pg_catalog | positionjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | positionsel | double
precision | internal, oid, internal, integer
pg_catalog | pow | double
precision | double precision, double precision
pg_catalog | pow | numeric
| numeric, numeric
pg_catalog | power | double
precision | double precision, double precision
pg_catalog | power | numeric
| numeric, numeric
pg_catalog | prsd_end | void
| internal
pg_catalog | prsd_headline | internal
| internal, internal, tsquery
pg_catalog | prsd_lextype | internal
| internal
pg_catalog | prsd_nexttoken | internal
| internal, internal, internal
pg_catalog | prsd_start | internal
| internal, integer
pg_catalog | pt_contained_circle | boolean
| point, circle
pg_catalog | pt_contained_poly | boolean
| point, polygon
pg_catalog | query_to_xml | xml
| query text, nulls boolean, tableforest boolean, targetns text
pg_catalog | query_to_xml_and_xmlschema | xml
| query text, nulls boolean, tableforest boolean, targetns text
pg_catalog | query_to_xmlschema | xml
| query text, nulls boolean, tableforest boolean, targetns text
pg_catalog | querytree | text
| tsquery
pg_catalog | quote_ident | text
| text
pg_catalog | quote_literal | text
| anyelement
pg_catalog | quote_literal | text
| text
pg_catalog | radians | double
precision | double precision
pg_catalog | radius | double
precision | circle
pg_catalog | random | double
precision |
pg_catalog | record_recv | record
| internal, oid, integer
pg_catalog | record_send | bytea
| record
pg_catalog | regclass | regclass
| text
pg_catalog | regclassrecv | regclass
| internal
pg_catalog | regclasssend | bytea
| regclass
pg_catalog | regconfigrecv | regconfig
| internal
pg_catalog | regconfigsend | bytea
| regconfig
pg_catalog | regdictionaryrecv |
regdictionary | internal
pg_catalog | regdictionarysend | bytea
| regdictionary
pg_catalog | regexeqjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | regexeqsel | double
precision | internal, oid, internal, integer
pg_catalog | regexnejoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | regexnesel | double
precision | internal, oid, internal, integer
pg_catalog | regexp_matches | setof
text[] | text, text
pg_catalog | regexp_matches | setof
text[] | text, text, text
pg_catalog | regexp_replace | text
| text, text, text
pg_catalog | regexp_replace | text
| text, text, text, text
pg_catalog | regexp_split_to_array | text[]
| text, text
pg_catalog | regexp_split_to_array | text[]
| text, text, text
pg_catalog | regexp_split_to_table | setof text
| text, text
pg_catalog | regexp_split_to_table | setof text
| text, text, text
pg_catalog | regoperatorrecv | regoperator
| internal
pg_catalog | regoperatorsend | bytea
| regoperator
pg_catalog | regoperrecv | regoper
| internal
pg_catalog | regopersend | bytea
| regoper
pg_catalog | regprocedurerecv |
regprocedure | internal
pg_catalog | regproceduresend | bytea
| regprocedure
pg_catalog | regprocrecv | regproc
| internal
pg_catalog | regprocsend | bytea
| regproc
pg_catalog | regtyperecv | regtype
| internal
pg_catalog | regtypesend | bytea
| regtype
pg_catalog | reltime | reltime
| interval
pg_catalog | reltimeeq | boolean
| reltime, reltime
pg_catalog | reltimege | boolean
| reltime, reltime
pg_catalog | reltimegt | boolean
| reltime, reltime
pg_catalog | reltimele | boolean
| reltime, reltime
pg_catalog | reltimelt | boolean
| reltime, reltime
pg_catalog | reltimene | boolean
| reltime, reltime
pg_catalog | reltimerecv | reltime
| internal
pg_catalog | reltimesend | bytea
| reltime
pg_catalog | repeat | text
| text, integer
pg_catalog | replace | text
| text, text, text
pg_catalog | round | double
precision | double precision
pg_catalog | round | numeric
| numeric
pg_catalog | round | numeric
| numeric, integer
pg_catalog | rpad | text
| text, integer
pg_catalog | rpad | text
| text, integer, text
pg_catalog | rtrim | text
| text
pg_catalog | rtrim | text
| text, text
pg_catalog | scalargtjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | scalargtsel | double
precision | internal, oid, internal, integer
pg_catalog | scalarltjoinsel | double
precision | internal, oid, internal, smallint
pg_catalog | scalarltsel | double
precision | internal, oid, internal, integer
pg_catalog | schema_to_xml | xml
| schema name, nulls boolean, tableforest boolean, targetns text
pg_catalog | schema_to_xml_and_xmlschema | xml
| schema name, nulls boolean, tableforest boolean, targetns text
pg_catalog | schema_to_xmlschema | xml
| schema name, nulls boolean, tableforest boolean, targetns text
pg_catalog | session_user | name
|
pg_catalog | set_bit | bytea
| bytea, integer, integer
pg_catalog | set_byte | bytea
| bytea, integer, integer
pg_catalog | set_config | text
| text, text, boolean
pg_catalog | set_masklen | cidr
| cidr, integer
pg_catalog | set_masklen | inet
| inet, integer
pg_catalog | setseed | void
| double precision
pg_catalog | setval | bigint
| regclass, bigint
pg_catalog | setval | bigint
| regclass, bigint, boolean
pg_catalog | setweight | tsvector
| tsvector, "char"
pg_catalog | shift_jis_2004_to_euc_jis_2004 | void
| integer, integer, cstring, internal, integer
pg_catalog | shift_jis_2004_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | shobj_description | text
| oid, name
pg_catalog | sign | double
precision | double precision
pg_catalog | sign | numeric
| numeric
pg_catalog | similar_escape | text
| text, text
pg_catalog | sin | double
precision | double precision
pg_catalog | sjis_to_euc_jp | void
| integer, integer, cstring, internal, integer
pg_catalog | sjis_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | sjis_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | slope | double
precision | point, point
pg_catalog | smgreq | boolean
| smgr, smgr
pg_catalog | smgrne | boolean
| smgr, smgr
pg_catalog | split_part | text
| text, text, integer
pg_catalog | sqrt | double
precision | double precision
pg_catalog | sqrt | numeric
| numeric
pg_catalog | statement_timestamp | timestamp
with time zone |
pg_catalog | string_to_array | text[]
| text, text
pg_catalog | strip | tsvector
| tsvector
pg_catalog | strpos | integer
| text, text
pg_catalog | substr | bytea
| bytea, integer
pg_catalog | substr | bytea
| bytea, integer, integer
pg_catalog | substr | text
| text, integer
pg_catalog | substr | text
| text, integer, integer
pg_catalog | substring | bit
| bit, integer
pg_catalog | substring | bit
| bit, integer, integer
pg_catalog | substring | bytea
| bytea, integer
pg_catalog | substring | bytea
| bytea, integer, integer
pg_catalog | substring | text
| text, integer
pg_catalog | substring | text
| text, integer, integer
pg_catalog | substring | text
| text, text
pg_catalog | substring | text
| text, text, text
pg_catalog | table_to_xml | xml
| tbl regclass, nulls boolean, tableforest boolean, targetns text
pg_catalog | table_to_xml_and_xmlschema | xml
| tbl regclass, nulls boolean, tableforest boolean, targetns text
pg_catalog | table_to_xmlschema | xml
| tbl regclass, nulls boolean, tableforest boolean, targetns text
pg_catalog | tan | double
precision | double precision
pg_catalog | text | text
| boolean
pg_catalog | text | text
| "char"
pg_catalog | text | text
| character
pg_catalog | text | text
| inet
pg_catalog | text | text
| name
pg_catalog | text | text
| xml
pg_catalog | text_ge | boolean
| text, text
pg_catalog | text_gt | boolean
| text, text
pg_catalog | text_larger | text
| text, text
pg_catalog | text_le | boolean
| text, text
pg_catalog | text_lt | boolean
| text, text
pg_catalog | text_pattern_eq | boolean
| text, text
pg_catalog | text_pattern_ge | boolean
| text, text
pg_catalog | text_pattern_gt | boolean
| text, text
pg_catalog | text_pattern_le | boolean
| text, text
pg_catalog | text_pattern_lt | boolean
| text, text
pg_catalog | text_pattern_ne | boolean
| text, text
pg_catalog | text_smaller | text
| text, text
pg_catalog | textanycat | text
| text, anynonarray
pg_catalog | textcat | text
| text, text
pg_catalog | texteq | boolean
| text, text
pg_catalog | texticlike | boolean
| text, text
pg_catalog | texticnlike | boolean
| text, text
pg_catalog | texticregexeq | boolean
| text, text
pg_catalog | texticregexne | boolean
| text, text
pg_catalog | textlen | integer
| text
pg_catalog | textlike | boolean
| text, text
pg_catalog | textne | boolean
| text, text
pg_catalog | textnlike | boolean
| text, text
pg_catalog | textrecv | text
| internal
pg_catalog | textregexeq | boolean
| text, text
pg_catalog | textregexne | boolean
| text, text
pg_catalog | textsend | bytea
| text
pg_catalog | thesaurus_init | internal
| internal
pg_catalog | thesaurus_lexize | internal
| internal, internal, internal, internal
pg_catalog | tideq | boolean
| tid, tid
pg_catalog | tidge | boolean
| tid, tid
pg_catalog | tidgt | boolean
| tid, tid
pg_catalog | tidlarger | tid
| tid, tid
pg_catalog | tidle | boolean
| tid, tid
pg_catalog | tidlt | boolean
| tid, tid
pg_catalog | tidne | boolean
| tid, tid
pg_catalog | tidrecv | tid
| internal
pg_catalog | tidsend | bytea
| tid
pg_catalog | tidsmaller | tid
| tid, tid
pg_catalog | time | time
without time zone | abstime
pg_catalog | time | time
without time zone | interval
pg_catalog | time | time
without time zone | timestamp without time zone
pg_catalog | time | time
without time zone | timestamp with time zone
pg_catalog | time | time
without time zone | time without time zone, integer
pg_catalog | time | time
without time zone | time with time zone
pg_catalog | time_cmp | integer
| time without time zone, time without time zone
pg_catalog | time_eq | boolean
| time without time zone, time without time zone
pg_catalog | time_ge | boolean
| time without time zone, time without time zone
pg_catalog | time_gt | boolean
| time without time zone, time without time zone
pg_catalog | time_hash | integer
| time without time zone
pg_catalog | time_larger | time
without time zone | time without time zone, time without time zone
pg_catalog | time_le | boolean
| time without time zone, time without time zone
pg_catalog | time_lt | boolean
| time without time zone, time without time zone
pg_catalog | time_mi_interval | time
without time zone | time without time zone, interval
pg_catalog | time_mi_time | interval
| time without time zone, time without time zone
pg_catalog | time_ne | boolean
| time without time zone, time without time zone
pg_catalog | time_pl_interval | time
without time zone | time without time zone, interval
pg_catalog | time_recv | time
without time zone | internal, oid, integer
pg_catalog | time_send | bytea
| time without time zone
pg_catalog | time_smaller | time
without time zone | time without time zone, time without time zone
pg_catalog | timedate_pl | timestamp
without time zone | time without time zone, date
pg_catalog | timemi | abstime
| abstime, reltime
pg_catalog | timenow | abstime
|
pg_catalog | timeofday | text
|
pg_catalog | timepl | abstime
| abstime, reltime
pg_catalog | timestamp | timestamp
without time zone | abstime
pg_catalog | timestamp | timestamp
without time zone | date
pg_catalog | timestamp | timestamp
without time zone | date, time without time zone
pg_catalog | timestamp | timestamp
without time zone | timestamp without time zone, integer
pg_catalog | timestamp | timestamp
without time zone | timestamp with time zone
pg_catalog | timestamp_cmp | integer
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_cmp_date | integer
| timestamp without time zone, date
pg_catalog | timestamp_cmp_timestamptz | integer
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_eq | boolean
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_eq_date | boolean
| timestamp without time zone, date
pg_catalog | timestamp_eq_timestamptz | boolean
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_ge | boolean
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_ge_date | boolean
| timestamp without time zone, date
pg_catalog | timestamp_ge_timestamptz | boolean
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_gt | boolean
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_gt_date | boolean
| timestamp without time zone, date
pg_catalog | timestamp_gt_timestamptz | boolean
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_hash | integer
| timestamp without time zone
pg_catalog | timestamp_larger | timestamp
without time zone | timestamp without time zone, timestamp without time
zone
pg_catalog | timestamp_le | boolean
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_le_date | boolean
| timestamp without time zone, date
pg_catalog | timestamp_le_timestamptz | boolean
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_lt | boolean
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_lt_date | boolean
| timestamp without time zone, date
pg_catalog | timestamp_lt_timestamptz | boolean
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_mi | interval
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_mi_interval | timestamp
without time zone | timestamp without time zone, interval
pg_catalog | timestamp_ne | boolean
| timestamp without time zone, timestamp without time zone
pg_catalog | timestamp_ne_date | boolean
| timestamp without time zone, date
pg_catalog | timestamp_ne_timestamptz | boolean
| timestamp without time zone, timestamp with time zone
pg_catalog | timestamp_pl_interval | timestamp
without time zone | timestamp without time zone, interval
pg_catalog | timestamp_recv | timestamp
without time zone | internal, oid, integer
pg_catalog | timestamp_send | bytea
| timestamp without time zone
pg_catalog | timestamp_smaller | timestamp
without time zone | timestamp without time zone, timestamp without time
zone
pg_catalog | timestamptypmodin | integer
| cstring[]
pg_catalog | timestamptz | timestamp
with time zone | abstime
pg_catalog | timestamptz | timestamp
with time zone | date
pg_catalog | timestamptz | timestamp
with time zone | date, time without time zone
pg_catalog | timestamptz | timestamp
with time zone | date, time with time zone
pg_catalog | timestamptz | timestamp
with time zone | timestamp without time zone
pg_catalog | timestamptz | timestamp
with time zone | timestamp with time zone, integer
pg_catalog | timestamptz_cmp | integer
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_cmp_date | integer
| timestamp with time zone, date
pg_catalog | timestamptz_cmp_timestamp | integer
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_eq | boolean
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_eq_date | boolean
| timestamp with time zone, date
pg_catalog | timestamptz_eq_timestamp | boolean
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_ge | boolean
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_ge_date | boolean
| timestamp with time zone, date
pg_catalog | timestamptz_ge_timestamp | boolean
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_gt | boolean
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_gt_date | boolean
| timestamp with time zone, date
pg_catalog | timestamptz_gt_timestamp | boolean
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_larger | timestamp
with time zone | timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_le | boolean
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_le_date | boolean
| timestamp with time zone, date
pg_catalog | timestamptz_le_timestamp | boolean
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_lt | boolean
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_lt_date | boolean
| timestamp with time zone, date
pg_catalog | timestamptz_lt_timestamp | boolean
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_mi | interval
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_mi_interval | timestamp
with time zone | timestamp with time zone, interval
pg_catalog | timestamptz_ne | boolean
| timestamp with time zone, timestamp with time zone
pg_catalog | timestamptz_ne_date | boolean
| timestamp with time zone, date
pg_catalog | timestamptz_ne_timestamp | boolean
| timestamp with time zone, timestamp without time zone
pg_catalog | timestamptz_pl_interval | timestamp
with time zone | timestamp with time zone, interval
pg_catalog | timestamptz_recv | timestamp
with time zone | internal, oid, integer
pg_catalog | timestamptz_send | bytea
| timestamp with time zone
pg_catalog | timestamptz_smaller | timestamp
with time zone | timestamp with time zone, timestamp with time zone
pg_catalog | timestamptztypmodin | integer
| cstring[]
pg_catalog | timetypmodin | integer
| cstring[]
pg_catalog | timetz | time with
time zone | timestamp with time zone
pg_catalog | timetz | time with
time zone | time without time zone
pg_catalog | timetz | time with
time zone | time with time zone, integer
pg_catalog | timetz_cmp | integer
| time with time zone, time with time zone
pg_catalog | timetz_eq | boolean
| time with time zone, time with time zone
pg_catalog | timetz_ge | boolean
| time with time zone, time with time zone
pg_catalog | timetz_gt | boolean
| time with time zone, time with time zone
pg_catalog | timetz_hash | integer
| time with time zone
pg_catalog | timetz_larger | time with
time zone | time with time zone, time with time zone
pg_catalog | timetz_le | boolean
| time with time zone, time with time zone
pg_catalog | timetz_lt | boolean
| time with time zone, time with time zone
pg_catalog | timetz_mi_interval | time with
time zone | time with time zone, interval
pg_catalog | timetz_ne | boolean
| time with time zone, time with time zone
pg_catalog | timetz_pl_interval | time with
time zone | time with time zone, interval
pg_catalog | timetz_recv | time with
time zone | internal, oid, integer
pg_catalog | timetz_send | bytea
| time with time zone
pg_catalog | timetz_smaller | time with
time zone | time with time zone, time with time zone
pg_catalog | timetzdate_pl | timestamp
with time zone | time with time zone, date
pg_catalog | timetztypmodin | integer
| cstring[]
pg_catalog | timezone | timestamp
without time zone | interval, timestamp with time zone
pg_catalog | timezone | timestamp
without time zone | text, timestamp with time zone
pg_catalog | timezone | timestamp
with time zone | interval, timestamp without time zone
pg_catalog | timezone | timestamp
with time zone | text, timestamp without time zone
pg_catalog | timezone | time with
time zone | interval, time with time zone
pg_catalog | timezone | time with
time zone | text, time with time zone
pg_catalog | tinterval | tinterval
| abstime, abstime
pg_catalog | tintervalct | boolean
| tinterval, tinterval
pg_catalog | tintervalend | abstime
| tinterval
pg_catalog | tintervaleq | boolean
| tinterval, tinterval
pg_catalog | tintervalge | boolean
| tinterval, tinterval
pg_catalog | tintervalgt | boolean
| tinterval, tinterval
pg_catalog | tintervalle | boolean
| tinterval, tinterval
pg_catalog | tintervalleneq | boolean
| tinterval, reltime
pg_catalog | tintervallenge | boolean
| tinterval, reltime
pg_catalog | tintervallengt | boolean
| tinterval, reltime
pg_catalog | tintervallenle | boolean
| tinterval, reltime
pg_catalog | tintervallenlt | boolean
| tinterval, reltime
pg_catalog | tintervallenne | boolean
| tinterval, reltime
pg_catalog | tintervallt | boolean
| tinterval, tinterval
pg_catalog | tintervalne | boolean
| tinterval, tinterval
pg_catalog | tintervalov | boolean
| tinterval, tinterval
pg_catalog | tintervalrecv | tinterval
| internal
pg_catalog | tintervalrel | reltime
| tinterval
pg_catalog | tintervalsame | boolean
| tinterval, tinterval
pg_catalog | tintervalsend | bytea
| tinterval
pg_catalog | tintervalstart | abstime
| tinterval
pg_catalog | to_ascii | text
| text
pg_catalog | to_ascii | text
| text, integer
pg_catalog | to_ascii | text
| text, name
pg_catalog | to_char | text
| bigint, text
pg_catalog | to_char | text
| double precision, text
pg_catalog | to_char | text
| integer, text
pg_catalog | to_char | text
| interval, text
pg_catalog | to_char | text
| numeric, text
pg_catalog | to_char | text
| real, text
pg_catalog | to_char | text
| timestamp without time zone, text
pg_catalog | to_char | text
| timestamp with time zone, text
pg_catalog | to_date | date
| text, text
pg_catalog | to_hex | text
| bigint
pg_catalog | to_hex | text
| integer
pg_catalog | to_number | numeric
| text, text
pg_catalog | to_timestamp | timestamp
with time zone | double precision
pg_catalog | to_timestamp | timestamp
with time zone | text, text
pg_catalog | to_tsquery | tsquery
| regconfig, text
pg_catalog | to_tsquery | tsquery
| text
pg_catalog | to_tsvector | tsvector
| regconfig, text
pg_catalog | to_tsvector | tsvector
| text
pg_catalog | transaction_timestamp | timestamp
with time zone |
pg_catalog | translate | text
| text, text, text
pg_catalog | trunc | double
precision | double precision
pg_catalog | trunc | macaddr
| macaddr
pg_catalog | trunc | numeric
| numeric
pg_catalog | trunc | numeric
| numeric, integer
pg_catalog | ts_debug | setof
record | config regconfig, document text, OUT alias text,
OUT description text, OUT token text, OUT dictionaries regdictionary[],
OUT dictionary regdictionary, OUT lexemes text[]
pg_catalog | ts_debug | setof
record | document text, OUT alias text, OUT description
text, OUT token text, OUT dictionaries regdictionary[], OUT dictionary
regdictionary, OUT lexemes text[]
pg_catalog | ts_headline | text
| regconfig, text, tsquery
pg_catalog | ts_headline | text
| regconfig, text, tsquery, text
pg_catalog | ts_headline | text
| text, tsquery
pg_catalog | ts_headline | text
| text, tsquery, text
pg_catalog | ts_lexize | text[]
| regdictionary, text
pg_catalog | ts_match_qv | boolean
| tsquery, tsvector
pg_catalog | ts_match_tq | boolean
| text, tsquery
pg_catalog | ts_match_tt | boolean
| text, text
pg_catalog | ts_match_vq | boolean
| tsvector, tsquery
pg_catalog | ts_parse | setof
record | parser_name text, txt text, OUT tokid integer,
OUT token text
pg_catalog | ts_parse | setof
record | parser_oid oid, txt text, OUT tokid integer, OUT
token text
pg_catalog | ts_rank | real
| real[], tsvector, tsquery
pg_catalog | ts_rank | real
| real[], tsvector, tsquery, integer
pg_catalog | ts_rank | real
| tsvector, tsquery
pg_catalog | ts_rank | real
| tsvector, tsquery, integer
pg_catalog | ts_rank_cd | real
| real[], tsvector, tsquery
pg_catalog | ts_rank_cd | real
| real[], tsvector, tsquery, integer
pg_catalog | ts_rank_cd | real
| tsvector, tsquery
pg_catalog | ts_rank_cd | real
| tsvector, tsquery, integer
pg_catalog | ts_rewrite | tsquery
| tsquery, text
pg_catalog | ts_rewrite | tsquery
| tsquery, tsquery, tsquery
pg_catalog | ts_stat | setof
record | query text, OUT word text, OUT ndoc integer, OUT
nentry integer
pg_catalog | ts_stat | setof
record | query text, weights text, OUT word text, OUT
ndoc integer, OUT nentry integer
pg_catalog | ts_token_type | setof
record | parser_name text, OUT tokid integer, OUT alias
text, OUT description text
pg_catalog | ts_token_type | setof
record | parser_oid oid, OUT tokid integer, OUT alias
text, OUT description text
pg_catalog | tsq_mcontained | boolean
| tsquery, tsquery
pg_catalog | tsq_mcontains | boolean
| tsquery, tsquery
pg_catalog | tsquery_and | tsquery
| tsquery, tsquery
pg_catalog | tsquery_cmp | integer
| tsquery, tsquery
pg_catalog | tsquery_eq | boolean
| tsquery, tsquery
pg_catalog | tsquery_ge | boolean
| tsquery, tsquery
pg_catalog | tsquery_gt | boolean
| tsquery, tsquery
pg_catalog | tsquery_le | boolean
| tsquery, tsquery
pg_catalog | tsquery_lt | boolean
| tsquery, tsquery
pg_catalog | tsquery_ne | boolean
| tsquery, tsquery
pg_catalog | tsquery_not | tsquery
| tsquery
pg_catalog | tsquery_or | tsquery
| tsquery, tsquery
pg_catalog | tsqueryrecv | tsquery
| internal
pg_catalog | tsquerysend | bytea
| tsquery
pg_catalog | tsvector_cmp | integer
| tsvector, tsvector
pg_catalog | tsvector_concat | tsvector
| tsvector, tsvector
pg_catalog | tsvector_eq | boolean
| tsvector, tsvector
pg_catalog | tsvector_ge | boolean
| tsvector, tsvector
pg_catalog | tsvector_gt | boolean
| tsvector, tsvector
pg_catalog | tsvector_le | boolean
| tsvector, tsvector
pg_catalog | tsvector_lt | boolean
| tsvector, tsvector
pg_catalog | tsvector_ne | boolean
| tsvector, tsvector
pg_catalog | tsvector_update_trigger | trigger
|
pg_catalog | tsvector_update_trigger_column | trigger
|
pg_catalog | tsvectorrecv | tsvector
| internal
pg_catalog | tsvectorsend | bytea
| tsvector
pg_catalog | txid_current | bigint
|
pg_catalog | txid_current_snapshot |
txid_snapshot |
pg_catalog | txid_snapshot_recv |
txid_snapshot | internal
pg_catalog | txid_snapshot_send | bytea
| txid_snapshot
pg_catalog | txid_snapshot_xip | setof
bigint | txid_snapshot
pg_catalog | txid_snapshot_xmax | bigint
| txid_snapshot
pg_catalog | txid_snapshot_xmin | bigint
| txid_snapshot
pg_catalog | txid_visible_in_snapshot | boolean
| bigint, txid_snapshot
pg_catalog | uhc_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | unknownrecv | unknown
| internal
pg_catalog | unknownsend | bytea
| unknown
pg_catalog | upper | text
| text
pg_catalog | utf8_to_ascii | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_big5 | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_euc_cn | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_euc_jis_2004 | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_euc_jp | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_euc_kr | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_euc_tw | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_gb18030 | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_gbk | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_iso8859 | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_iso8859_1 | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_johab | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_koi8r | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_shift_jis_2004 | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_sjis | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_uhc | void
| integer, integer, cstring, internal, integer
pg_catalog | utf8_to_win | void
| integer, integer, cstring, internal, integer
pg_catalog | uuid_cmp | integer
| uuid, uuid
pg_catalog | uuid_eq | boolean
| uuid, uuid
pg_catalog | uuid_ge | boolean
| uuid, uuid
pg_catalog | uuid_gt | boolean
| uuid, uuid
pg_catalog | uuid_hash | integer
| uuid
pg_catalog | uuid_le | boolean
| uuid, uuid
pg_catalog | uuid_lt | boolean
| uuid, uuid
pg_catalog | uuid_ne | boolean
| uuid, uuid
pg_catalog | uuid_recv | uuid
| internal
pg_catalog | uuid_send | bytea
| uuid
pg_catalog | varbit | bit varying
| bit varying, integer, boolean
pg_catalog | varbit_recv | bit varying
| internal, oid, integer
pg_catalog | varbit_send | bytea
| bit varying
pg_catalog | varbitcmp | integer
| bit varying, bit varying
pg_catalog | varbiteq | boolean
| bit varying, bit varying
pg_catalog | varbitge | boolean
| bit varying, bit varying
pg_catalog | varbitgt | boolean
| bit varying, bit varying
pg_catalog | varbitle | boolean
| bit varying, bit varying
pg_catalog | varbitlt | boolean
| bit varying, bit varying
pg_catalog | varbitne | boolean
| bit varying, bit varying
pg_catalog | varbittypmodin | integer
| cstring[]
pg_catalog | varchar | character
varying | character varying, integer, boolean
pg_catalog | varchar | character
varying | name
pg_catalog | varcharrecv | character
varying | internal, oid, integer
pg_catalog | varcharsend | bytea
| character varying
pg_catalog | varchartypmodin | integer
| cstring[]
pg_catalog | version | text
|
pg_catalog | width | double
precision | box
pg_catalog | width_bucket | integer
| double precision, double precision, double precision, integer
pg_catalog | width_bucket | integer
| numeric, numeric, numeric, integer
pg_catalog | win1250_to_latin2 | void
| integer, integer, cstring, internal, integer
pg_catalog | win1250_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | win1251_to_iso | void
| integer, integer, cstring, internal, integer
pg_catalog | win1251_to_koi8r | void
| integer, integer, cstring, internal, integer
pg_catalog | win1251_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | win1251_to_win866 | void
| integer, integer, cstring, internal, integer
pg_catalog | win866_to_iso | void
| integer, integer, cstring, internal, integer
pg_catalog | win866_to_koi8r | void
| integer, integer, cstring, internal, integer
pg_catalog | win866_to_mic | void
| integer, integer, cstring, internal, integer
pg_catalog | win866_to_win1251 | void
| integer, integer, cstring, internal, integer
pg_catalog | win_to_utf8 | void
| integer, integer, cstring, internal, integer
pg_catalog | xideq | boolean
| xid, xid
pg_catalog | xideqint4 | boolean
| xid, integer
pg_catalog | xidrecv | xid
| internal
pg_catalog | xidsend | bytea
| xid
pg_catalog | xml | xml
| text
pg_catalog | xml_recv | xml
| internal
pg_catalog | xml_send | bytea
| xml
pg_catalog | xmlcomment | xml
| text
pg_catalog | xmlconcat2 | xml
| xml, xml
pg_catalog | xmlvalidate | boolean
| xml, text
pg_catalog | xpath | xml[]
| text, xml
pg_catalog | xpath | xml[]
| text, xml, text[]
public | drop_table | integer
|
public | foo | setof text
|
public | plfoo | setof text
|
(1858 rows)

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:35:20
Message-ID: 9361.1232044520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> 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


From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:41:10
Message-ID: 603c8f070901151041i5a7e64cejf7c9e1aff9813180@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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


From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 18:44:57
Message-ID: 603c8f070901151044n4c287ac7v784e3c25ce87ef1a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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


From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: jd(at)commandprompt(dot)com
Cc: "Greg Stark" <greg(dot)stark(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 18:46:08
Message-ID: 603c8f070901151046u75c5abby92a858d9d73cde82@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> I know I already posted this but it seems the most useful behavior is to
> just change the sort. It doesn't change any behavior in terms of
> flags/switches so there is nothing new to learn. It just changes the
> output.

That's better than nothing, but it still doesn't help when I want to do:

psql -c '\df' | grep bool

This is not a made-up use case.

...Robert


From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 19:26:28
Message-ID: 20090115192627.GE20296@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jan 15, 2009 at 01:06:22PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 19:38:16
Message-ID: 10245.1232048296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Robert Haas" <robertmhaas(at)gmail(dot)com> 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


From: David Fetter <david(at)fetter(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: jd(at)commandprompt(dot)com, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 19:44:32
Message-ID: 20090115194432.GF20296@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jan 15, 2009 at 01:46:08PM -0500, Robert Haas wrote:
> > I know I already posted this but it seems the most useful behavior is to
> > just change the sort. It doesn't change any behavior in terms of
> > flags/switches so there is nothing new to learn. It just changes the
> > output.
>
> That's better than nothing, but it still doesn't help when I want to do:
>
> psql -c '\df' | grep bool

psql -c '\dfS' |grep bool

> This is not a made-up use case.

Nor is does this long overdue change impose an undue burden on it :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, jd(at)commandprompt(dot)com, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 19:59:00
Message-ID: 10548.1232049540@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> On Thu, Jan 15, 2009 at 01:46:08PM -0500, Robert Haas wrote:
>> That's better than nothing, but it still doesn't help when I want to do:
>> psql -c '\df' | grep bool

> psql -c '\dfS' |grep bool

That presumes the opposite case, when you only want to see system
functions.

I hesitate to suggest this, but maybe an acceptable compromise is
\df -> old behavior
\dfS -> only system functions
\dfU -> only user functions

I do not actually believe that either of the latter really makes
sense in combination with a pattern, but if people are going to
insist on seeing a misleading view of the system state, let's at
least make it symmetric.

regards, tom lane


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 20:03:46
Message-ID: 496F96A2.1090303@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 20:07:54
Message-ID: 117A9FC5-AE7F-4540-B732-4483A605251F@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Le 15 janv. 09 à 17:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :

> Peter Eisentraut <peter_e(at)gmx(dot)net> 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.

Maybe it does so much 'cause you're developing system functions. I've
yet to try it but think it's a good feature.

What about a new \dfU listing only non system objects ( User ones ) ?

--
dim


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 20:27:29
Message-ID: 10953.1232051249@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> 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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 20:39:52
Message-ID: 11161.1232051992@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Le 15 janv. 09 17:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a crit :
>> I agree, this change mostly sucks, and particularly with respect to
>> \df.

> Maybe it does so much 'cause you're developing system functions.

No, I hardly ever use \df on a function I'm working on just at the
moment, because I know what it's supposed to be. It's remembering
functions that I haven't used lately that is the issue.

> I've yet to try it but think it's a good feature.
^^^^^^^^^^^^^^^^^^

Indeed...

> What about a new \dfU listing only non system objects ( User ones ) ?

\dfS together with \dfU would at least be a reasonably symmetric
extension. I'm still of the opinion that neither is really a very
helpful thing to use in connection with a pattern.

regards, tom lane


From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-01-15 20:48:51
Message-ID: 861562C7-A1DA-4A40-B72D-DD2851D3E9CE@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Le 15 janv. 09 à 21:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
> \dfS together with \dfU would at least be a reasonably symmetric
> extension. I'm still of the opinion that neither is really a very
> helpful thing to use in connection with a pattern.

I completly agree with the idea of showing things respecting current
search_path for pattern matches.

Even more so now that I've read the thread.
--
dim


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 21:26:37
Message-ID: 603c8f070901151326o42fe6b1bp6056779e839fefc1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jan 15, 2009 at 3:03 PM, Josh Berkus <josh(at)agliodbs(dot)com> 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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 21:34:09
Message-ID: 496FABD1.1060104@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 21:46:06
Message-ID: 12739.1232055966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> 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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 21:53:00
Message-ID: 496FB03C.1050000@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.)

Hmmmm, 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


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:10:24
Message-ID: 603c8f070901151410w32fb832bideaa66c0fa2bed23@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:12:47
Message-ID: 13150.1232057567@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> 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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:21:48
Message-ID: 20090115222148.GP4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:24:24
Message-ID: 13316.1232058264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> 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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:32:26
Message-ID: 496FB97A.5040500@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:49:09
Message-ID: 603c8f070901151449x71ab4438lfc396d2537826928@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>> 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


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 22:51:18
Message-ID: 1232059878.12600.283.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <please specify \dfU or \dfS or \dfA)

Where \dfU is users, \dfS is system and \dfA is all (as a compromise).

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-15 23:01:37
Message-ID: 13829.1232060497@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> 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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 01:19:27
Message-ID: 20090116011927.GQ4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Joshua D. Drake (jd(at)commandprompt(dot)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 <please specify \dfU or \dfS or \dfA)

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. That's
a better compromise than both changing \df *and* making it useless, if
we have to compromise.

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.

Thanks,

Stephen


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 01:24:23
Message-ID: 496FE1C7.2060704@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 01:25:52
Message-ID: 16821.1232069152@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> 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


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 01:40:39
Message-ID: 1232070040.30828.3.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, 2009-01-15 at 20:25 -0500, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> 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: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 02:09:11
Message-ID: 603c8f070901151809w62a8aac8ka9c8dafe79847c29@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jan 15, 2009 at 8:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> 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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:08:03
Message-ID: 496FFA13.4080001@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:15:29
Message-ID: 20090116031529.GR4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Josh Berkus (josh(at)agliodbs(dot)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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:28:25
Message-ID: 20090116032824.GS4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> 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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:31:39
Message-ID: 27104.1232076699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> 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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:36:45
Message-ID: 20090116033645.GT4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh,

* Josh Berkus (josh(at)agliodbs(dot)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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:41:29
Message-ID: 20090116034129.GU4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> 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 \. <shrug> I wouldn't complain
about a more generic aliasing ability in psql, mind you.

Thanks,

Stephen


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:42:21
Message-ID: 27263.1232077341@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> 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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:50:23
Message-ID: 20090116035022.GV4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 03:58:12
Message-ID: 27467.1232078292@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> 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


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 04:00:39
Message-ID: 20090116040039.GK6440@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane escribió:
> Stephen Frost <sfrost(at)snowman(dot)net> 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 Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 04:07:19
Message-ID: 20090116040719.GW4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 04:13:25
Message-ID: 20090116041325.GX4656@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro,

* Alvaro Herrera (alvherre(at)commandprompt(dot)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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 04:19:01
Message-ID: 49700AB5.4080605@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 04:26:33
Message-ID: 49700C79.9040106@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 07:14:34
Message-ID: 1232090074.20154.1.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 12:24:20
Message-ID: 49707C74.1000506@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvherre(at)commandprompt(dot)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


From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 15:52:22
Message-ID: 87iqofdz9l.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Well, as I said before, I'm not averse to having the default behavior
> *with no pattern* to be that we omit system objects --- and I think we
> could make that apply across the board. What I'm saying is that when
> you give a pattern it should not matter whether an object is system or
> user. It would go like this:
>
> \df -- all non-system functions
> \df sin -- the active (visible) definition of sin()
> \df sin* -- all visible functions starting with "sin"
>
> lesser used cases:
>
> \df * -- all visible functions
> \df *.* -- all functions, period
> \df pg_catalog.* -- all system functions
> \df public.* -- all functions in public

So it seems to me that we made \df consistent with \dt when in fact what we
really wanted is for it to be consistent with \d. I hadn't actually realized
that the behaviour for \d was so different from \dt myself.

The behaviour of \dt in the face of tables which shadow system tables is
actually even stranger:

postgres=# create table pg_proc (t text);
CREATE TABLE
postgres=# commit;
COMMIT
postgres=# \dt pg_proc
No matching relations found.

And I don't see any reason aggregates, operators, etc, shouldn't be any more
susceptible the shadowing problem.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 16:36:45
Message-ID: 7317.1232123805@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> So it seems to me that we made \df consistent with \dt when in fact what we
> really wanted is for it to be consistent with \d. I hadn't actually realized
> that the behaviour for \d was so different from \dt myself.

Yeah, given that the battle cry for this patch was "let's make
everything consistent", it seems like some attention should be paid to
that.

I think that when everybody got tired of arguing yesterday, the last
idea left standing was

* revert \df to its former behavior, ie doesn't care if
functions are system or user
* \dfS will restrict the printout to system functions
* \dfU will restrict the printout to non-system functions

where "system function" means "it's in the pg_catalog schema".
(Presumably this means that "\dfS public.*" fails to print anything ...
is that okay?)

I suggest that we make all the \d commands work like that, including
\d and \dt.

One issue here is that plain \d gets less useful because it'll now
include system catalogs. We could add the additional rule that
the above statements apply only when a pattern is specified, and
without a pattern you get just user stuff (so omitting a pattern
corresponds to pattern "*" with the U modifier, not just "*").
This would probably make it a bit easier to have exactly the same
rules across the board.

Again, "\dfS" would be a bit useless, unless we say that the implicit
U modifier for no pattern doesn't override an explicit S modifier.

Comments? Does this cover all the cases?

regards, tom lane


From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:14:49
Message-ID: 2489998D-D530-45CB-80F8-F14BB8084261@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:

> One issue here is that plain \d gets less useful because it'll now
> include system catalogs. We could add the additional rule that
> the above statements apply only when a pattern is specified, and
> without a pattern you get just user stuff (so omitting a pattern
> corresponds to pattern "*" with the U modifier, not just "*").
> This would probably make it a bit easier to have exactly the same
> rules across the board.
>
> Again, "\dfS" would be a bit useless, unless we say that the implicit
> U modifier for no pattern doesn't override an explicit S modifier.
>
> Comments? Does this cover all the cases?

So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
something?

David


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:20:29
Message-ID: 1232126429.16299.13.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, 2009-01-16 at 09:14 -0800, David E. Wheeler wrote:
> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
>
> > One issue here is that plain \d gets less useful because it'll now
> > include system catalogs. We could add the additional rule that
> > the above statements apply only when a pattern is specified, and
> > without a pattern you get just user stuff (so omitting a pattern
> > corresponds to pattern "*" with the U modifier, not just "*").
> > This would probably make it a bit easier to have exactly the same
> > rules across the board.
> >
> > Again, "\dfS" would be a bit useless, unless we say that the implicit
> > U modifier for no pattern doesn't override an explicit S modifier.
> >
> > Comments? Does this cover all the cases?
>
> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
> something?

\df would act as it does now. Showing you *everything*.

Joshua D. Drake

>
> David
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:35:55
Message-ID: 8331.1232127355@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
>> Comments? Does this cover all the cases?

> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
> something?

You mean "\dfU"? Yes, if there's no pattern.

regards, tom lane


From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:37:01
Message-ID: afe0c4a25b35f815db84a24c166b404a@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> One issue here is that plain \d gets less useful because it'll now
> include system catalogs.

Are you kidding me? No way. That's a recipe for making all our users
unhappy with us.

> * \dfU will restrict the printout to non-system functions

Sorry, but the "U" is ugly and unnecessary. The *default* should always
be user-defined functions, and to hide the internals. Hence, we have a
special flag for when you know what you are doing and want to see the system
information: "S".

I do agree that \d is not consistent with anything else, but let's not
throw the baby out with the bathwater. Or if we do, let's not have \d
show sequences either, because that part always annoyed me. :)

> Comments? Does this cover all the cases?

No: the user case someone had upthread, where they want to see all their
functions starting with an "a" across all schemas in their path:

\df a*

This should act similar to how \dt does right now:

\dt p*

Such that it shows only the user's functions, and only the user's tables.
99% of the time, people don't care about or want to see the 60+ internal
functions starting with "a", and the 40 or so internal tables
starting with "p".

I'm willing to concede some of the "\d.{1} objectname" behavior, but I don't
think we should mess at all with "\d" or "\dt" because people are used
to the current behavior, and its rather sane and useful (unlike \df)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200901161234
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAklwxXgACgkQvJuQZxSWSsgawACeMox6/RveSyvRJ4gpe/TiLSR3
YeYAoOBxy6IpTLdHYI40haMAgCebobLB
=Dj3a
-----END PGP SIGNATURE-----


From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:37:47
Message-ID: CF82EFCF-0BB3-4A9F-8431-E1D6C051B9BE@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Jan 16, 2009, at 9:35 AM, Tom Lane wrote:

>> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
>> something?
>
> You mean "\dfU"? Yes, if there's no pattern.

Yeah, that's what I meant. Thanks. +1.

Best,

David


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jd(at)commandprompt(dot)com
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:40:02
Message-ID: 8419.1232127602@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> On Fri, 2009-01-16 at 09:14 -0800, David E. Wheeler wrote:
>> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
>>> One issue here is that plain \d gets less useful because it'll now
>>> include system catalogs. We could add the additional rule that
>>> the above statements apply only when a pattern is specified, and
>>> without a pattern you get just user stuff (so omitting a pattern
>>> corresponds to pattern "*" with the U modifier, not just "*").
>>> This would probably make it a bit easier to have exactly the same
>>> rules across the board.
>>>
>>> Again, "\dfS" would be a bit useless, unless we say that the implicit
>>> U modifier for no pattern doesn't override an explicit S modifier.
>>>
>>> Comments? Does this cover all the cases?
>>
>> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
>> something?

> \df would act as it does now. Showing you *everything*.

Which part of the quoted paragraph didn't you read?

regards, tom lane


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:44:18
Message-ID: 1232127858.16299.23.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, 2009-01-16 at 12:40 -0500, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:

> >>> Again, "\dfS" would be a bit useless, unless we say that the implicit
> >>> U modifier for no pattern doesn't override an explicit S modifier.
> >>>
> >>> Comments? Does this cover all the cases?
> >>
> >> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
> >> something?
>
> > \df would act as it does now. Showing you *everything*.
>
> Which part of the quoted paragraph didn't you read?

Apparently at least part. Sorry for the noise.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:55:53
Message-ID: 8733.1232128553@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> Comments? Does this cover all the cases?

> No: the user case someone had upthread, where they want to see all their
> functions starting with an "a" across all schemas in their path:

> \df a*

I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close
approximation to that. The behavior you are asking for is essentially
"I want to pay attention to the search path, except not actually follow
its rules", which is bogus. Either you want to see the functions you
can call without schema qualification, or you want to see 'em all ---
it does no good whatsoever to lie about the visibility.

regards, tom lane


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 17:56:57
Message-ID: 603c8f070901160956p5f2ad369u8f82a0aceb120b5c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> One issue here is that plain \d gets less useful because it'll now
> include system catalogs. We could add the additional rule that
> the above statements apply only when a pattern is specified, and
> without a pattern you get just user stuff (so omitting a pattern
> corresponds to pattern "*" with the U modifier, not just "*").
> This would probably make it a bit easier to have exactly the same
> rules across the board.

Changing the scope of the search on the basis of whether or not a
pattern is present strikes me as a terrible idea. It's confusing and
unlikely to make anyone happy.

...Robert


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:09:18
Message-ID: 8994.1232129358@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Changing the scope of the search on the basis of whether or not a
> pattern is present strikes me as a terrible idea. It's confusing and
> unlikely to make anyone happy.

Huh? The pattern itself "changes the scope of the search", so I don't
see how this is a conceptual violation.

Not that I'd personally be unhappy with dropping that part of the
proposal, but this doesn't seem like a good argument against it.

regards, tom lane


From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:24:42
Message-ID: ad71b65e16de5543298a86fb580d292b@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close
> approximation to that. The behavior you are asking for is essentially
> "I want to pay attention to the search path, except not actually follow
> its rules", which is bogus. Either you want to see the functions you
> can call without schema qualification, or you want to see 'em all ---
> it does no good whatsoever to lie about the visibility.

But that's what \dt and \di and \dv have done since forever, and I've
never heard a single complaint about it.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200901161321
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAklw0MwACgkQvJuQZxSWSsj5LQCeIl2j+/fT2v0G6aZ/0UnRcCVl
xUoAnj1OBE8mPL9qJHxo+ETwWSHrfFJj
=vtEm
-----END PGP SIGNATURE-----


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:25:56
Message-ID: 603c8f070901161025g6ea595am4961443d133ba414@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Jan 16, 2009 at 1:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Changing the scope of the search on the basis of whether or not a
>> pattern is present strikes me as a terrible idea. It's confusing and
>> unlikely to make anyone happy.
>
> Huh? The pattern itself "changes the scope of the search", so I don't
> see how this is a conceptual violation.
>
> Not that I'd personally be unhappy with dropping that part of the
> proposal, but this doesn't seem like a good argument against it.

I don't understand your confusion. You're once again proposing to
have \df display only user functions, and \df <pattern> search both
user and system functions. That doesn't seem remotely sane to me.
Now I do "\df"and get a list of 30 functions, and that's more than I
want to wade through so I do "\df a*" and get a list of 60 functions.
Yuck!

I feel pretty strongly that making the pattern search against a
different list of stuff than what the same command would display
without the pattern is confusing and a bad idea. It's a bad idea
regardless of which particular backslash-sequence we're talking about.
It doesn't work that way in 8.3.x, it doesn't work that way in CVS
HEAD, and it seems quite obvious it will confuse and annoy end-users.

...Robert


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:37:55
Message-ID: 9435.1232131075@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I feel pretty strongly that making the pattern search against a
> different list of stuff than what the same command would display
> without the pattern is confusing and a bad idea. It's a bad idea
> regardless of which particular backslash-sequence we're talking about.

Well, I'm perfectly happy to drop that stipulation and just go with

\df -- all
\dfS -- system only
\dfU -- non-system only

but are we willing to change \d and \dt to work that way too?
Or should we leave them inconsistent?

regards, tom lane


From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:43:58
Message-ID: 1232131438.16299.31.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, 2009-01-16 at 13:37 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I feel pretty strongly that making the pattern search against a
> > different list of stuff than what the same command would display
> > without the pattern is confusing and a bad idea. It's a bad idea
> > regardless of which particular backslash-sequence we're talking about.
>
> Well, I'm perfectly happy to drop that stipulation and just go with
>
> \df -- all
> \dfS -- system only
> \dfU -- non-system only
>
> but are we willing to change \d and \dt to work that way too?
> Or should we leave them inconsistent?
>

I would prefer them consistent.

Joshua D. Drake

> regards, tom lane
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:52:52
Message-ID: 4970D784.4050503@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I feel pretty strongly that making the pattern search against a
>> different list of stuff than what the same command would display
>> without the pattern is confusing and a bad idea. It's a bad idea
>> regardless of which particular backslash-sequence we're talking about.
>
> Well, I'm perfectly happy to drop that stipulation and just go with
>
> \df -- all
> \dfS -- system only
> \dfU -- non-system only
>
> but are we willing to change \d and \dt to work that way too?
> Or should we leave them inconsistent?

I think changing \dt would confuse the heck out of people. Far more
than changing \df to be consistent with \dt would be.

So my votes, in order of preference, are:

1) make \df consistent with \dt
2) leave them inconsistent

--Josh


From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 18:54:33
Message-ID: 7F47F65E-8833-4251-AB2D-1A0CB3714775@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote:

>> \df -- all
>> \dfS -- system only
>> \dfU -- non-system only
>>
>> but are we willing to change \d and \dt to work that way too?
>> Or should we leave them inconsistent?
>
> I would prefer them consistent.

I think that people will hate the changed behavior to \d and \dt.

Best,

David


From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Brendan Jurd" <direvus(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, <pgsql-hackers(at)postgresql(dot)org>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 19:17:52
Message-ID: 49708900.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Comments? Does this cover all the cases?

I tend to think that changing which schemas are searched based on the
presence or absence of a search pattern is a bad idea.

Is the bare form (no U or S) going to search all schemas or the ones
on the search path? Whatever the answer, do we need a way to get the
other?

+1 for consistency across all \d commands, even though I almost always
want to see just the user objects. IMO it's worth the extra keystroke
to be sure of what I'm seeing.

-Kevin


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 19:37:48
Message-ID: 10240.1232134668@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote:
>>> but are we willing to change \d and \dt to work that way too?
>>> Or should we leave them inconsistent?
>>
>> I would prefer them consistent.

> I think that people will hate the changed behavior to \d and \dt.

Yeah, one of the advantages of the simpler proposal is that the behavior
of plain \df doesn't change from what it was, so there's no surprise
factor, just a couple of new options. But if we apply that same
behavior to \d and \dt then we do have a change in default behavior.
The point of "assume U for no pattern" was to preserve the default
behavior of those two commands.

Actually, now that I look at the code, the historical behavior of
\d is even weirder than I thought:

\d or \d+ *with no pattern* is equivalent to \dtvs(+)
(and hence shows all user tables and no system tables)

\d or \d+ *with a pattern* takes a completely different
code path that has no system-vs-user special behavior,
ie it's about like the historical \df behavior

which means that Robert's complaint about treating no-pattern
differently from pattern falls to the ground. It's exactly what
\d has done for years, and nobody has complained about that.

regards, tom lane


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 19:43:14
Message-ID: 10350.1232134994@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close
>> approximation to that. The behavior you are asking for is essentially
>> "I want to pay attention to the search path, except not actually follow
>> its rules", which is bogus. Either you want to see the functions you
>> can call without schema qualification, or you want to see 'em all ---
>> it does no good whatsoever to lie about the visibility.

> But that's what \dt and \di and \dv have done since forever, and I've
> never heard a single complaint about it.

The reason it's not really an issue for those is that we still maintain
the convention that system catalogs have names beginning with "pg_",
and most people still avoid such names for user tables, and so there is
no conflict that search path order would matter for. With function
names there is no such standard and thus far greater risk of collisions.
It is a serious, serious error to suppose that behavior that is good
enough for tables (and in fact was designed before we had schemas...)
is also good enough for functions.

regards, tom lane


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 19:44:06
Message-ID: 4970E386.7030104@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom,

> which means that Robert's complaint about treating no-pattern
> differently from pattern falls to the ground. It's exactly what
> \d has done for years, and nobody has complained about that.

Just because they haven't voiced loud complaints doesn't mean that they
haven't been *confused* by it. I know that I've been confused by the
behaviour of \d before, which is why I pretty much never use it.

I think a search of -general and -newbie would be educational on the
number of people who are confused by the shortcuts.

Or, to put it another way, the fact that we screwed up in the past is
hardly a justification to do it in the future.

--Josh


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 19:50:20
Message-ID: 603c8f070901161150r2c6224ddmaa63a7cca6af3644@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Jan 16, 2009 at 1:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I feel pretty strongly that making the pattern search against a
>> different list of stuff than what the same command would display
>> without the pattern is confusing and a bad idea. It's a bad idea
>> regardless of which particular backslash-sequence we're talking about.
>
> Well, I'm perfectly happy to drop that stipulation and just go with
>
> \df -- all
> \dfS -- system only
> \dfU -- non-system only
>
> but are we willing to change \d and \dt to work that way too?
> Or should we leave them inconsistent?

I think you should make:

\df - non-system only
\dfS - system only
\dfA - all

Then you could make \dt the same way, and it wouldn't involve breaking
the way \dt works now.

...Robert


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 20:01:43
Message-ID: 10700.1232136103@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Tom,
>> which means that Robert's complaint about treating no-pattern
>> differently from pattern falls to the ground. It's exactly what
>> \d has done for years, and nobody has complained about that.

> Just because they haven't voiced loud complaints doesn't mean that they
> haven't been *confused* by it. I know that I've been confused by the
> behaviour of \d before, which is why I pretty much never use it.

> I think a search of -general and -newbie would be educational on the
> number of people who are confused by the shortcuts.

> Or, to put it another way, the fact that we screwed up in the past is
> hardly a justification to do it in the future.

Well, the only reason for proposing the special case for no-pattern
was to provide some modicum of backward compatibility for \d and \dt.
If we want to decide that those are screwed up anyway and we should
make them work more like the other ones, that'd be okay with me.
But I have gotten the clear impression that such a proposal isn't
going to get majority support.

I think though that your confusion may come from an aspect of \d's
behavior that is more or less orthogonal to what we've been discussing:
without a pattern it equates to \dtvs, that is you get a summary
one-line-per-relation display of tables, views, and sequences; whereas
with a pattern it does something entirely different, to wit you get a
verbose display about each matching relation. Maybe we should
reconsider that bit; but it's a different argument from the one about
system vs user objects.

[ thinks a bit... ] One interesting idea is to go with the all/S/U
behavior for \dt, but to define bare "\d" as meaning "\dtvsU" not
just "\dtvs". That keeps backwards compatibility for that specific
case without introducing any conceptual inconsistency into the rest of
the command set.

regards, tom lane


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 20:03:05
Message-ID: 603c8f070901161203o1aef43bdheb837f45057f055@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> Actually, now that I look at the code, the historical behavior of
> \d is even weirder than I thought:
>
> \d or \d+ *with no pattern* is equivalent to \dtvs(+)
> (and hence shows all user tables and no system tables)
>
> \d or \d+ *with a pattern* takes a completely different
> code path that has no system-vs-user special behavior,
> ie it's about like the historical \df behavior
>
> which means that Robert's complaint about treating no-pattern
> differently from pattern falls to the ground. It's exactly what
> \d has done for years, and nobody has complained about that.

Well, the behavior of \d with a pattern is almost totally useless
right now. Probably no one is doing "\d a*" because it produces an
obscene amount of output (or if you don't have more than one table
with a, then pick some other letter). On the other hand "\dt a*" does
something very nice that is just what you might expect.

But you're right: my facts were wrong with respect to treating
no-pattern differently than pattern. I don't think that makes the
point invalid. I can't shake the feeling that this is about a couple
of PostgreSQL hackers (yourself included) not wanting to type \dfS or
\dfA or something to get the behavior they currently get with \df. If
that's the case, come off it, because there's lots of evidence on this
thread (and in all likelihood elsewhere) that this behavior is not
what end-users want.

Making \df only show user functions, and "\df <pattern>" only search
user functions, is going to make a LOT of people happy (perhaps after
5 minutes of initial confusion). If it makes three developers
unhappy, it's worth it - especially because the developers can easily
add a switch, backslash command, environment variable setting, or
whatever they want to still be able to have it the way they like it.
By all means, add a setting that includes system stuff without having
to type an extra letter - just don't make it the default.

...Robert


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 20:06:17
Message-ID: 10875.1232136377@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think you should make:

> \df - non-system only
> \dfS - system only
> \dfA - all

> Then you could make \dt the same way, and it wouldn't involve breaking
> the way \dt works now.

No, instead it would break \df. As I said before, a solution that was
designed for tables back around 6.4 isn't good enough for functions
in a schema world.

regards, tom lane


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Brendan Jurd" <direvus(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 20:10:40
Message-ID: 11003.1232136640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Is the bare form (no U or S) going to search all schemas or the ones
> on the search path? Whatever the answer, do we need a way to get the
> other?

The former, if you specify "*.*" (or "*.anything") as your pattern.
The latter, if you don't specify a schema qualifier in your pattern.
This already works and has since 7.3; I don't think we need to embed
any such semantics in the command names.

regards, tom lane


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 20:16:56
Message-ID: 11119.1232137016@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I can't shake the feeling that this is about a couple
> of PostgreSQL hackers (yourself included) not wanting to type \dfS or
> \dfA or something to get the behavior they currently get with \df. If
> that's the case, come off it, because there's lots of evidence on this
> thread (and in all likelihood elsewhere) that this behavior is not
> what end-users want.

As was made clear at the beginning of the thread, that's what they
*think* they want, without any experience with a system that actually
behaves that way. And yes I do believe I know better, both from knowing
how the system works and from actual experience with the ill-considered
patch that's now in HEAD. I'm willing to provide a "U" modifier but
I think it will be a serious error to make that the default behavior.

regards, tom lane


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-16 22:41:35
Message-ID: 603c8f070901161441q7c01e8ffwb494420dd0b63c51@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Jan 16, 2009 at 3:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I can't shake the feeling that this is about a couple
>> of PostgreSQL hackers (yourself included) not wanting to type \dfS or
>> \dfA or something to get the behavior they currently get with \df. If
>> that's the case, come off it, because there's lots of evidence on this
>> thread (and in all likelihood elsewhere) that this behavior is not
>> what end-users want.
>
> As was made clear at the beginning of the thread, that's what they
> *think* they want, without any experience with a system that actually
> behaves that way. And yes I do believe I know better, both from knowing
> how the system works and from actual experience with the ill-considered
> patch that's now in HEAD. I'm willing to provide a "U" modifier but
> I think it will be a serious error to make that the default behavior.

1. Providing the U modifier is a step in the right direction.

2. I agree that developers sometimes know better than users what users
actually want. I have a pretty good track record there myself.

3. On this thread, we have you, Peter Eisentraut, and Heikki
Linnakangas arguing for reverting the default behavior of \df, and we
have (by my tally, apologies to anyone I've missed or misrepresented)
Greg Sabino Mullane, Josh Berkus, Josh Drake, Greg Stark, David
Fetter, Dmitri Fontaine, Stephen Frost, and myself expressing support
for the change (with various differences of opinion on what other
alternatives might not or might not be better). So in this case I
think you don't know better.

However, by my count, zero of the people who like the change are
committers and all of the people who don't like it are, so we may be
out of luck. :-)

...Robert


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 02:13:48
Message-ID: 200901200213.n0K2Dms23221@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Gregory Stark wrote:
> The behaviour of \dt in the face of tables which shadow system tables is
> actually even stranger:
>
> postgres=# create table pg_proc (t text);
> CREATE TABLE
> postgres=# commit;
> COMMIT
> postgres=# \dt pg_proc
> No matching relations found.
>
>
> And I don't see any reason aggregates, operators, etc, shouldn't be any more
> susceptible the shadowing problem.

The inconsistency between \d and \dt is not defensible, and no one said
they liked it. Here is an example:

test=> \d pg_language
--> Table "pg_catalog.pg_language"
Column | Type | Modifiers
---------------+-----------+-----------
lanname | name | not null
lanowner | oid | not null
lanispl | boolean | not null
lanpltrusted | boolean | not null
lanplcallfoid | oid | not null
lanvalidator | oid | not null
lanacl | aclitem[] |
Indexes:
"pg_language_name_index" UNIQUE, btree (lanname)
"pg_language_oid_index" UNIQUE, btree (oid)

test=> \dt pg_language
--> No matching relations found.

As you can see, \d shows system tables, while \dt does not. The
attached patch makes \d and \dt consistent:

test=> \d pg_language
Did not find any relation named "pg_language".

test=> \dt pg_language
No matching relations found.

test=> \dS pg_language
Table "pg_catalog.pg_language"
Column | Type | Modifiers
---------------+-----------+-----------
lanname | name | not null
lanowner | oid | not null
lanispl | boolean | not null
lanpltrusted | boolean | not null
lanplcallfoid | oid | not null
lanvalidator | oid | not null
lanacl | aclitem[] |
Indexes:
"pg_language_name_index" UNIQUE, btree (lanname)
"pg_language_oid_index" UNIQUE, btree (oid)

test=> \dtS pg_language
List of relations
Schema | Name | Type | Owner
------------+-------------+-------+----------
pg_catalog | pg_language | table | postgres
(1 row)

In pre-8.4, 'S' was recognised only by \dt.

The other part of the patch shows system and _user_ tables when \dtS is
used, to be consistent with the rest of the \d* commands.

I know we don't like the current behavior, but I think we need to make
them consistent first for easy testing and so when we change it, it will
remain consistent.

Applied. I will work on a consensus patch soon for the new behavior.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/pgpatches/psql-d text/x-diff 4.9 KB

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 04:12:30
Message-ID: 200901200412.n0K4CUX12917@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian wrote:
> I know we don't like the current behavior, but I think we need to make
> them consistent first for easy testing and so when we change it, it will
> remain consistent.
>
> I will work on a consensus patch soon for the new behavior.

Here is what I hope is a consensus patch. It adds 'A' to show all
objects, including system ones. It turns out that this is how 'S' works
now in CVS, but 'S' is unclear because it suggests just system objects;
'A' for show 'all' objects seems clearer.

I did not add any special handling for patterns:

test=> \df repeat
List of functions
Schema | Name | Result data type | Argument data types
--------+------+------------------+---------------------
(0 rows)

test=> \dfA repeat
List of functions
Schema | Name | Result data type | Argument data types
------------+--------+------------------+---------------------
pg_catalog | repeat | text | text, integer
(1 row)

I am afraid that special pattern rules are going to be too confusing.
You can see only system objects by referencing pg_catalog:

test=> \dtA pg_catalog.pg_t*
List of relations
Schema | Name | Type | Owner
------------+------------------+-------+----------
pg_catalog | pg_tablespace | table | postgres
pg_catalog | pg_trigger | table | postgres
pg_catalog | pg_ts_config | table | postgres
pg_catalog | pg_ts_config_map | table | postgres
pg_catalog | pg_ts_dict | table | postgres
pg_catalog | pg_ts_parser | table | postgres
pg_catalog | pg_ts_template | table | postgres
pg_catalog | pg_type | table | postgres
(8 rows)

Patch attached. One interesting idea would be to assume 'A' if the
a schema is specified in the pattern, so;

\df pg_catalog.*

would work without 'A'.

With this patch, \d and \dt show only user tables, and \df shows only
user functions. I think usability-wise, these are good, and \dA, \dtA,
and \dfA include system tables and functions.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/pgpatches/psql-A text/x-diff 14.7 KB

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 04:57:14
Message-ID: 603c8f070901192057m156af3a8oa7a17878095b7fe2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> Here is what I hope is a consensus patch. It adds 'A' to show all
> objects, including system ones. It turns out that this is how 'S' works
> now in CVS, but 'S' is unclear because it suggests just system objects;
> 'A' for show 'all' objects seems clearer.

I think it's probably fine for "S" to mean "include system objects"
rather than "show only system objects". Everyone should be relatively
used to "S" by now; I think it's less confusing to keep the same
letter even if the behavior has been adjusted somewhat. Though others
may disagree?

(Although this met with some earlier opposition, mostly from Tom IIRC,
I still think it might be useful to have a setting to control which
types of system objects are displayed by default: the setting could be
interpreted as a list of characters X for which \dX would include
system objects even without S. This would allow people who liked the
old behavior to mostly recreate it.)

...Robert


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:17:23
Message-ID: 200901201517.n0KFHNn24949@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas wrote:
> > Here is what I hope is a consensus patch. It adds 'A' to show all
> > objects, including system ones. It turns out that this is how 'S' works
> > now in CVS, but 'S' is unclear because it suggests just system objects;
> > 'A' for show 'all' objects seems clearer.
>
> I think it's probably fine for "S" to mean "include system objects"
> rather than "show only system objects". Everyone should be relatively
> used to "S" by now; I think it's less confusing to keep the same
> letter even if the behavior has been adjusted somewhat. Though others
> may disagree?

OK, so you are saying you like the behavior in current CVS, which uses
'S' as you described.

In thinking last night, I am now wondering if a letter is really the
right symbol for this. We already have letter flags which control
object type selection, but the system table addition is kind of
independent of those flags, like '+' now. I am thinking maybe '&' is
the right symbol rather than 'A' or 'S'.

\df

and

\df&

'&' would stand for "and system objects". We could use '*' but that
might be confused with a wildcard symbol.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:32:29
Message-ID: 20090120153228.GD3940@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian escribió:

> In thinking last night, I am now wondering if a letter is really the
> right symbol for this. We already have letter flags which control
> object type selection, but the system table addition is kind of
> independent of those flags, like '+' now. I am thinking maybe '&' is
> the right symbol rather than 'A' or 'S'.

& is probably going to be useful as a modifier when we have concurrent
psql, so I suggest you do not use it here. Or maybe not, but in any
case see
http://archives.postgresql.org/message-id/8204.1207689056%40sss.pgh.pa.us
before you use &.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:33:09
Message-ID: 404c0f98ef0f040c4d122803c5b766e8@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> In thinking last night, I am now wondering if a letter is really the
> right symbol for this. We already have letter flags which control
> object type selection, but the system table addition is kind of
> independent of those flags, like '+' now. I am thinking maybe '&' is
> the right symbol rather than 'A' or 'S'.

What problem are we trying to solve here that is not already solved by
using 'S' for system tables, which has been in use in psql for over a
decade now?

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200901201026
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkl17psACgkQvJuQZxSWSsjdRACgoAJPOBsWYPf420KLl/7tuPTa
By0AoORZBVnszD5SmGUpKvBHR7YFES7r
=AILx
-----END PGP SIGNATURE-----


From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:38:28
Message-ID: 200901201638.30786.dfontaine@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Le mardi 20 janvier 2009, Bruce Momjian a écrit :
> Robert Haas wrote:
> > > Here is what I hope is a consensus patch. It adds 'A' to show all
> > > objects, including system ones. It turns out that this is how 'S'
> > > works now in CVS, but 'S' is unclear because it suggests just system
> > > objects; 'A' for show 'all' objects seems clearer.
> >
> > I think it's probably fine for "S" to mean "include system objects"
> > rather than "show only system objects". Everyone should be relatively
> > used to "S" by now; I think it's less confusing to keep the same
> > letter even if the behavior has been adjusted somewhat. Though others
> > may disagree?

I still think that given a pattern, psql commands should simply mimic whatever
is the server way of using search_path. I'd really like \df foo and \d foo to
follow the same rules as my production queries wrt to how to find objects
when I'm too lazy to schema qualify their name.

Now, it's been advocated for the sake of simplicity to have with-pattern and
without-pattern options behave roughly the same way. I can't find it
difficult to explain the two behaviours here, all the more when looking at
current \d and \dt differences.

What I'd like to propose is for \df without pattern to behave exactly like \df
with pattern, *including* wrt to ordering the output. Functions listed in
search_path order, pg_catalog implicitly part of it, but as its *last*
element. Or whatever server object lookup code sayth.

> '&' would stand for "and system objects". We could use '*' but that
> might be confused with a wildcard symbol.

If you insist on treating system object differently than server itself, I'd
prefer for the client not to have me use well known non-alpha keys, which a
lot of shells associate to e.g. jobs processing (bash, csh, lftp, some more
I'm sure).

Regards,
--
dim


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:38:54
Message-ID: 20090120153854.GA32428@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> In thinking last night, I am now wondering if a letter is really the
> right symbol for this. We already have letter flags which control
> object type selection, but the system table addition is kind of
> independent of those flags, like '+' now. I am thinking maybe '&' is
> the right symbol rather than 'A' or 'S'.

This really feels like over-engineering at this point. I don't
particularly like '&', and 'S' has been in use like this for quite
some time.

Stephen


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:42:36
Message-ID: 200901201542.n0KFgaV29667@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > In thinking last night, I am now wondering if a letter is really the
> > right symbol for this. We already have letter flags which control
> > object type selection, but the system table addition is kind of
> > independent of those flags, like '+' now. I am thinking maybe '&' is
> > the right symbol rather than 'A' or 'S'.
>
> & is probably going to be useful as a modifier when we have concurrent
> psql, so I suggest you do not use it here. Or maybe not, but in any
> case see
> http://archives.postgresql.org/message-id/8204.1207689056%40sss.pgh.pa.us
> before you use &.

Yea, I thought '&' might be coming for that someday. I figured it
wouldn't be used for backslash commands, but why confuse things.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 15:44:06
Message-ID: 200901201544.n0KFi6x29926@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> > In thinking last night, I am now wondering if a letter is really the
> > right symbol for this. We already have letter flags which control
> > object type selection, but the system table addition is kind of
> > independent of those flags, like '+' now. I am thinking maybe '&' is
> > the right symbol rather than 'A' or 'S'.
>
> What problem are we trying to solve here that is not already solved by
> using 'S' for system tables, which has been in use in psql for over a
> decade now?

Well, the 'S' behavior used to be only system, now it is _add_ system.
Anyway, 'S' is still probably the best choice.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-20 16:18:20
Message-ID: 200901201618.n0KGIKG12375@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Dimitri Fontaine wrote:
-- Start of PGP signed section.
> Le mardi 20 janvier 2009, Bruce Momjian a ?crit?:
> > Robert Haas wrote:
> > > > Here is what I hope is a consensus patch. It adds 'A' to show all
> > > > objects, including system ones. It turns out that this is how 'S'
> > > > works now in CVS, but 'S' is unclear because it suggests just system
> > > > objects; 'A' for show 'all' objects seems clearer.
> > >
> > > I think it's probably fine for "S" to mean "include system objects"
> > > rather than "show only system objects". Everyone should be relatively
> > > used to "S" by now; I think it's less confusing to keep the same
> > > letter even if the behavior has been adjusted somewhat. Though others
> > > may disagree?
>
> I still think that given a pattern, psql commands should simply mimic whatever
> is the server way of using search_path. I'd really like \df foo and \d foo to
> follow the same rules as my production queries wrt to how to find objects
> when I'm too lazy to schema qualify their name.
>
> Now, it's been advocated for the sake of simplicity to have with-pattern and
> without-pattern options behave roughly the same way. I can't find it
> difficult to explain the two behaviours here, all the more when looking at
> current \d and \dt differences.

The \d and \dt differences are fixed/gone in current CVS.

> What I'd like to propose is for \df without pattern to behave exactly like \df
> with pattern, *including* wrt to ordering the output. Functions listed in
> search_path order, pg_catalog implicitly part of it, but as its *last*
> element. Or whatever server object lookup code sayth.

I personally liked the idea of searching pg_catalog for a pattern, but
what turned me against it was this behavior:

\d
long list of user tables

and then the user wants to see just the tables that begin with 'p':

\d p*
list of system and user tables that start with 'p'

All of a sudden they see many system tables. It is hard to call that
behavior logical or expected. One unusual approach would be to search
pg_catalog only when a _non-wildcard_ pattern was supplied, so:

\d p*

would show user tables beginning with 'p', but:

\d pg_class

would find the 'pg_class' table that is the search path, typically from
pg_catalog. It might be a little awkward to document, but might be the
most acceptable solution. The very good argument _against_ this
solution is that:

\d pg_class*

would show no rows while:

\d pg_class

would show the pg_catalog entry. This is also odd and unexpected, which
led me to just having people use 'S' when they want pg_catalog involved.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 14:42:59
Message-ID: 49773473.2090207@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian wrote:
> Bruce Momjian wrote:
>> I know we don't like the current behavior, but I think we need to make
>> them consistent first for easy testing and so when we change it, it will
>> remain consistent.
>>
>> I will work on a consensus patch soon for the new behavior.
>

The "\dXU *.*" commands also display objects from information_schema. IMHO
these should also be classified as system objects. It is most annoying to
run '\dfU *.*' and see a list of information_schema internal functions show up.
Whereas the intent was to see the user defined functions in all schemas.

regards,
Martin


From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 15:12:36
Message-ID: 87ab9kofq3.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:

> Bruce Momjian wrote:
>> Bruce Momjian wrote:
>>> I know we don't like the current behavior, but I think we need to make
>>> them consistent first for easy testing and so when we change it, it will
>>> remain consistent.
>>>
>>> I will work on a consensus patch soon for the new behavior.
>>
>
> The "\dXU *.*" commands also display objects from information_schema. IMHO
> these should also be classified as system objects. It is most annoying to
> run '\dfU *.*' and see a list of information_schema internal functions show up.
> Whereas the intent was to see the user defined functions in all schemas.

You know I think I've come around to agreeing with one of Tom's proposals.

I think we should do the following:

\dX : list user objects
\dXS : list system objects
\dX <pat> : list all matching objects based on search_path
\dX *.* : list all objects in all schemas

I've basically come to the conclusion that having the output agree with
behaviour at run-time is a big advantage and anything else would actually be
too dangerous.

If you do something like "\dt p*" or "\df a*" and are annoyed by the output
you just have to make your pattern something more specific. For tables we
already prefix them all with pg_ so one more letter ought to be enough.

For functions it would be nice if we could trim the output quite a bit. I
wonder if we could rename all our internal functions which implement operators
and indexam methods without introducing any backwards compatibility issues. We
don't document things like "int4gt" after all.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 17:29:42
Message-ID: 200901211929.44450.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 17:49:13
Message-ID: 200901211749.n0LHnDY18707@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 18:09:28
Message-ID: 20090121180928.GJ4038@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 18:44:29
Message-ID: 200901211844.n0LIiTW08768@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 18:54:57
Message-ID: 20090121185457.GM4038@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 19:01:19
Message-ID: 200901211901.n0LJ1J710991@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 19:05:25
Message-ID: 20090121190525.GN4038@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 19:22:31
Message-ID: 200901211922.n0LJMWw18773@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-21 20:10:10
Message-ID: 603c8f070901211210x1433b95di4dd356ebb69d4444@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-22 02:23:54
Message-ID: 20090122022354.GE32428@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-22 02:32:26
Message-ID: 20090122023226.GF32428@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce, et al,

* Bruce Momjian (bruce(at)momjian(dot)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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-01-23 00:03:58
Message-ID: 21351.1232669038@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> 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


From: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-01 04:54:08
Message-ID: 21BCA8A7-F5D0-4682-BECC-95DEEFA625C3@pointblue.com.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 23 Jan 2009, at 00:03, Tom Lane wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> 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.

was it that easy, or I got it wrong?

:)

Attachment Content-Type Size
psql_du_conlogin.patch application/octet-stream 531 bytes

From: David Fetter <david(at)fetter(dot)org>
To: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-01 10:58:44
Message-ID: 20090201105844.GI17601@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Sun, Feb 01, 2009 at 04:54:08AM +0000, Grzegorz Jaskiewicz wrote:
>
> On 23 Jan 2009, at 00:03, Tom Lane wrote:
>
>> Stephen Frost <sfrost(at)snowman(dot)net> 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.
>
> was it that easy, or I got it wrong?
>
> :)

I think Stephen meant that they should add a column to the output.
Stephen?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


From: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-01 11:07:50
Message-ID: AEF1B76D-AE98-4A30-ABB0-C7561DFD6272@pointblue.com.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 1 Feb 2009, at 10:58, David Fetter wrote:
>
> I think Stephen meant that they should add a column to the output.
> Stephen?

it's already there.
try:
psql -E
\du

;]


From: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
To: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
Cc: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-01 11:12:58
Message-ID: D2C6E871-A420-4643-B9BA-93D3E7222DF7@pointblue.com.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 1 Feb 2009, at 11:07, Grzegorz Jaskiewicz wrote:

>
> On 1 Feb 2009, at 10:58, David Fetter wrote:
>>
>> I think Stephen meant that they should add a column to the output.
>> Stephen?
>
> it's already there.

oh sorry, column - as in psql printout's column....
yeah, doable too - lemme see if I can do it.


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: David Fetter <david(at)fetter(dot)org>
Cc: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-01 14:21:18
Message-ID: 20090201142118.GN8123@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

* David Fetter (david(at)fetter(dot)org) wrote:
> On Sun, Feb 01, 2009 at 04:54:08AM +0000, Grzegorz Jaskiewicz wrote:
> > On 23 Jan 2009, at 00:03, Tom Lane wrote:
> >> Stephen Frost <sfrost(at)snowman(dot)net> 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.
> >
> > was it that easy, or I got it wrong?
> >
> > :)
>
> I think Stephen meant that they should add a column to the output.
> Stephen?

It was, but that was before the output-as-table changes were done. It
looks like when those were committed, 'Cannot login' was added as an
attribute. Having 'Can login' (as this patch proposes) seems reasonable
to me.

On a side note, I have to say that I'm not exactly thrilled with the new
table-\du, especially since the List of roles isn't set up to break
across lines cleanly.

So if you have alot of roles granted, and even a couple attributes, it
gets ugly..

Stephen


From: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-01 14:23:54
Message-ID: 20B1A93C-3FBA-4ADA-A65C-33F28500E11E@pointblue.com.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 1 Feb 2009, at 14:21, Stephen Frost wrote:
>

>
> So if you have alot of roles granted, and even a couple attributes, it
> gets ugly..

true.

I thought perhaps you guys want to go for table chart

USER\t PERM1\t PERM2\t PERM3
foo\to\tx\tx\o
bar\tx\to\to\x
....

Personaly that would work for me, but that's probably the very
argument the whole thread was devoted to.


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated backslash consistency patch
Date: 2009-02-07 19:58:21
Message-ID: 200902071958.n17JwLh17209@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost wrote:
-- Start of PGP signed section.
> * David Fetter (david(at)fetter(dot)org) wrote:
> > On Sun, Feb 01, 2009 at 04:54:08AM +0000, Grzegorz Jaskiewicz wrote:
> > > On 23 Jan 2009, at 00:03, Tom Lane wrote:
> > >> Stephen Frost <sfrost(at)snowman(dot)net> 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.
> > >
> > > was it that easy, or I got it wrong?
> > >
> > > :)
> >
> > I think Stephen meant that they should add a column to the output.
> > Stephen?
>
> It was, but that was before the output-as-table changes were done. It
> looks like when those were committed, 'Cannot login' was added as an
> attribute. Having 'Can login' (as this patch proposes) seems reasonable
> to me.

We only document non-default settings, which is why 'can login' was
skipped, which I think is logical so I think the existing code is fine.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>
Subject: Re: FWD: Re: Updated backslash consistency patch
Date: 2009-02-07 21:38:06
Message-ID: 200902072138.n17Lc6W12069@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce, et al,
>
> * Bruce Momjian (bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +