Re: psql \d* and system objects

The psql system object display issue has not been completely resolved
for 8.4; see 8.4 open items:

http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes

So what is the proposal? Have U/S/A flags for all commands and have
different system display default for each command?

I think this:

http://archives.postgresql.org/pgsql-hackers/2009-01/msg01443.php

makes a strong argument that having a pattern control system object
display will be too confusing.

FYI, right now 'S' is "include-system"; we have no system-only display
option.

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

Bruce Momjian escreveu:
> The psql system object display issue has not been completely resolved
> for 8.4; see 8.4 open items:
>
> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>
> So what is the proposal? Have U/S/A flags for all commands and have
> different system display default for each command?
>
[I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
variable? The point in providing metacommands is facility. If we're using a
psql variable, we don't need to add another character to distinguish between
system, user, or both. Also, I don't think people frequently change the search
class (system, user, or both) so I don't buy the argument that it is more
easier to type another letter each time than typing a '\set FOO bar' once per
dozens of commands.

--
Euler Taveira de Oliveira
http://www.timbira.com/

Euler Taveira de Oliveira wrote:
> Bruce Momjian escreveu:
> > The psql system object display issue has not been completely resolved
> > for 8.4; see 8.4 open items:
> >
> > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
> >
> > So what is the proposal? Have U/S/A flags for all commands and have
> > different system display default for each command?
> >
> [I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
> variable? The point in providing metacommands is facility. If we're using a
> psql variable, we don't need to add another character to distinguish between
> system, user, or both. Also, I don't think people frequently change the search
> class (system, user, or both) so I don't buy the argument that it is more
> easier to type another letter each time than typing a '\set FOO bar' once per
> dozens of commands.

I think the problem is that people often use \dt and then \df or \dT,
and odds are they would want different system-visible behavior for
those. I think we could have a setting that would choose a default of
'user-only', or 'all', but I still think we would need the ability to
override it at command time.

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

On Sat, Mar 28, 2009 at 1:25 AM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> Bruce Momjian escreveu:
>> The psql system object display issue has not been completely resolved
>> for 8.4;  see 8.4 open items:
>>
>>       http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>>
>> So what is the proposal?  Have U/S/A flags for all commands and have
>> different system display default for each command?
>>
> [I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
> variable? The point in providing metacommands is facility. If we're using a
> psql variable, we don't need to add another character to distinguish between
> system, user, or both. Also, I don't think people frequently change the search
> class (system, user, or both) so I don't buy the argument that it is more
> easier to type another letter each time than typing a '\set FOO bar' once per
> dozens of commands.

I think you should reconsider your non-buying of that argument. That
would be really, really annoying for me. Most of the time I want to
look at a user object. But every now and then I want to look at a
system object. Having to type two commands to get that would be
completely annoying.

...Robert

On Sat, Mar 28, 2009 at 4:25 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Euler Taveira de Oliveira wrote:
>> Bruce Momjian escreveu:
>> > The psql system object display issue has not been completely resolved
>> > for 8.4;  see 8.4 open items:
>> >
>> >     http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>> >
>> > So what is the proposal?  Have U/S/A flags for all commands and have
>> > different system display default for each command?
>> >
>> [I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
>> variable? The point in providing metacommands is facility. If we're using a
>> psql variable, we don't need to add another character to distinguish between
>> system, user, or both. Also, I don't think people frequently change the search
>> class (system, user, or both) so I don't buy the argument that it is more
>> easier to type another letter each time than typing a '\set FOO bar' once per
>> dozens of commands.
>
> I think the problem is that people often use \dt and then \df or \dT,
> and odds are they would want different system-visible behavior for
> those.  I think we could have a setting that would choose a default of
> 'user-only', or 'all', but I still think we would need the ability to
> override it at command time.

Yeah, I like this. I think we could even make it a little more
fine-tuned. For example you might have an option whose values is a
list of object types for which system tables are excluded by default,
with * meaning all. So you could have:

tsv = exclude system tables, sequences, and views by default
tsvf = exclude system tables, sequences, views, and functions by default
* = don't show any system objects by default
empty string = show all system objects by default

I don't really care about the details, just suggesting it would be
useful to be able to tune by object type.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think you should reconsider your non-buying of that argument. That
> would be really, really annoying for me. Most of the time I want to
> look at a user object. But every now and then I want to look at a
> system object.

I still think that this argument is fundamentally misguided, at least
with respect to the case where a pattern is given. If I say "\df sin"
I should see the definition of sin(). I do not care in the slightest
whether it's a system or user function.

This behavior (seen in HEAD) is absolutely bogus:

regression=# select sin(0.5);
sin
-------------------
0.479425538604203
(1 row)

regression=# \df sin
List of functions
Schema | Name | Result data type | Argument data types
--------+------+------------------+---------------------
(0 rows)

But it gets worse:

regression=# create function sin(float8) returns float8 as
regression-# 'select $1 + 1' language sql;
CREATE FUNCTION
regression=# select sin(0.5);
sin
-------------------
0.479425538604203 -- user might be expecting 1.5 here
(1 row)

regression=# \df sin
List of functions
Schema | Name | Result data type | Argument data types
--------+------+------------------+---------------------
(0 rows)

Now I *have* a user function named sin(), it's not getting called
(which might surprise me if I didn't know there was a conflicting
system function) and \df doesn't show me either one.

I actually was expecting the above example to show me the user function,
which I was then going to rant about being a lie. But the actual
behavior is even worse than that.

There is not anything that is not broken about HEAD's behavior,
and the sooner we admit that the sooner we can get to a fix.
Slicing the categorization more finely or in different ways is
not going to improve matters: the concept that there is a categorization
that will make it hide requested objects is wrong to begin with.

regards, tom lane

Tom Lane wrote:
> I actually was expecting the above example to show me the user function,
> which I was then going to rant about being a lie. But the actual
> behavior is even worse than that.
>
> There is not anything that is not broken about HEAD's behavior,
> and the sooner we admit that the sooner we can get to a fix.
> Slicing the categorization more finely or in different ways is
> not going to improve matters: the concept that there is a categorization
> that will make it hide requested objects is wrong to begin with.

You can say it is broken, but what is your proposal?

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

On Sun, Mar 29, 2009 at 1:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Now I *have* a user function named sin(), it's not getting called
> (which might surprise me if I didn't know there was a conflicting
> system function) and \df doesn't show me either one.
>
> I actually was expecting the above example to show me the user function,
> which I was then going to rant about being a lie.  But the actual
> behavior is even worse than that.

Well, that is clearly a bug.

> There is not anything that is not broken about HEAD's behavior,
> and the sooner we admit that the sooner we can get to a fix.
> Slicing the categorization more finely or in different ways is
> not going to improve matters: the concept that there is a categorization
> that will make it hide requested objects is wrong to begin with.

Well, by that argument, 8.3 is broken, too, because it hides
pg_catalog tables, views, sequences, and indices. It's fair to say
that the system shouldn't hide "requested" objects, but sometimes
people want request only the objects that they created, and not the
ones that are part of the system. In 8.3, if you want to list all of
the functions you've defined (as opposed to the ones that came with
the system), you have a couple of not-so-fun options:

1. pg_dump -s | grep 'CREATE.*FUNCTION'
2. looking up the **40-line** query that \df issues, modifying it to
exclude system functions, and running it by hand

This has been a huge irritation to me for many years, and (whatever
else you can say about the patch that started all this) it makes this
particular thing a whole lot easier. I'd like to find a way to still
have that be easy while fixing some of the other issues.

Even in 8.3, we have this oddness:

\dt pg_index
No matching relations found.
select sum(1) from pg_index;
sum
-----
332
(1 row)

One idea I had is to issue some kind of a warning if a \d command
matches system objects that are excluded from the output, like this:

note: %d system objects also found, use %s to display

...Robert

Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). I actually have a patch that does
that, attached. (It is from January so might need adjustment.)

---------------------------------------------------------------------------

Robert Haas wrote:
> On Sun, Mar 29, 2009 at 1:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Now I *have* a user function named sin(), it's not getting called
> > (which might surprise me if I didn't know there was a conflicting
> > system function) and \df doesn't show me either one.
> >
> > I actually was expecting the above example to show me the user function,
> > which I was then going to rant about being a lie. ?But the actual
> > behavior is even worse than that.
>
> Well, that is clearly a bug.
>
> > There is not anything that is not broken about HEAD's behavior,
> > and the sooner we admit that the sooner we can get to a fix.
> > Slicing the categorization more finely or in different ways is
> > not going to improve matters: the concept that there is a categorization
> > that will make it hide requested objects is wrong to begin with.
>
> Well, by that argument, 8.3 is broken, too, because it hides
> pg_catalog tables, views, sequences, and indices. It's fair to say
> that the system shouldn't hide "requested" objects, but sometimes
> people want request only the objects that they created, and not the
> ones that are part of the system. In 8.3, if you want to list all of
> the functions you've defined (as opposed to the ones that came with
> the system), you have a couple of not-so-fun options:
>
> 1. pg_dump -s | grep 'CREATE.*FUNCTION'
> 2. looking up the **40-line** query that \df issues, modifying it to
> exclude system functions, and running it by hand
>
> This has been a huge irritation to me for many years, and (whatever
> else you can say about the patch that started all this) it makes this
> particular thing a whole lot easier. I'd like to find a way to still
> have that be easy while fixing some of the other issues.
>
> Even in 8.3, we have this oddness:
>
> \dt pg_index
> No matching relations found.
> select sum(1) from pg_index;
> sum
> -----
> 332
> (1 row)
>
> One idea I had is to issue some kind of a warning if a \d command
> matches system objects that are excluded from the output, like this:
>
> note: %d system objects also found, use %s to display
>
> ...Robert

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

On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Maybe the best we are going to do is to have any pattern supplied to \d*
> assume 'S' (include system objects).  I actually have a patch that does
> that, attached. (It is from January so might need adjustment.)

That still has the problem that "\df a*" is horribly inconsistent with
"\df". It might be reasonable to assume that if a name without
wildcards is given to any \d command, it should display whatever
object it finds, user or system - but I can't see doing it for any
wildcard at all.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> That still has the problem that "\df a*" is horribly inconsistent with
> "\df". It might be reasonable to assume that if a name without
> wildcards is given to any \d command, it should display whatever
> object it finds, user or system - but I can't see doing it for any
> wildcard at all.

Why not? Seems "horribly inconsistent" to me to treat those cases
differently.

It seems entirely explainable to me to say that "if you specify
no pattern, the default behavior is to list all non-system functions".
Where the patch went wrong is in fooling with the behavior when a
pattern is specified.

regards, tom lane

On Mon, Mar 30, 2009 at 10:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> That still has the problem that "\df a*" is horribly inconsistent with
>> "\df".  It might be reasonable to assume that if a name without
>> wildcards is given to any \d command, it should display whatever
>> object it finds, user or system - but I can't see doing it for any
>> wildcard at all.
>
> Why not?  Seems "horribly inconsistent" to me to treat those cases
> differently.
>
> It seems entirely explainable to me to say that "if you specify
> no pattern, the default behavior is to list all non-system functions".
> Where the patch went wrong is in fooling with the behavior when a
> pattern is specified.

Well, what am I supposed to do when I have a large number of
user-defined functions and want only the ones whose names start with
a?

What I like about this patch is that you can search by function (or
aggregate, etc.) name, and, independently of whether you search or
display all, you can include or exclude system functions. I think
that's a good design. Now, we can argue about what the default
behavior should be, but at the very minimum I think all combinations
of <search pattern, no search pattern> and <user-defined only, all>
should be possible with some relatively small number of keystrokes.

...Robert

Robert Haas wrote:
> On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Maybe the best we are going to do is to have any pattern supplied to \d*
> > assume 'S' (include system objects). ?I actually have a patch that does
> > that, attached. (It is from January so might need adjustment.)
>
> That still has the problem that "\df a*" is horribly inconsistent with
> "\df". It might be reasonable to assume that if a name without
> wildcards is given to any \d command, it should display whatever
> object it finds, user or system - but I can't see doing it for any
> wildcard at all.

I think you are re-iterating the URL I referenced when I started this
thread:

http://archives.postgresql.org/pgsql-hackers/2009-01/msg01443.php

I think the big question is whether the inconsistency (pattern implies
'S') is worth accepting for greater usability.

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

On Mon, Mar 30, 2009 at 10:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > Maybe the best we are going to do is to have any pattern supplied to \d*
>> > assume 'S' (include system objects). ?I actually have a patch that does
>> > that, attached. (It is from January so might need adjustment.)
>>
>> That still has the problem that "\df a*" is horribly inconsistent with
>> "\df".  It might be reasonable to assume that if a name without
>> wildcards is given to any \d command, it should display whatever
>> object it finds, user or system - but I can't see doing it for any
>> wildcard at all.
>
> I think you are re-iterating the URL I referenced when I started this
> thread:
>
>        http://archives.postgresql.org/pgsql-hackers/2009-01/msg01443.php
>
> I think the big question is whether the inconsistency (pattern implies
> 'S') is worth accepting for greater usability.

The inconsistency would be less objectionable if there were a way to
override it when it's not what you want.

...Robert

Hi,

Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
> I think the big question is whether the inconsistency (pattern implies
> 'S') is worth accepting for greater usability.

My answer is yes, please, definitely, go for it.
We don't need idiot-proof easy to remember semantics, we need useful
ones... The former category is already taken care of by some other
open source database software, have I been told...

What about a mail with some content? Look, a user-level proposal
draft! :)
\dt lists user tables only
\dtS lists system tables only
\dt pattern lists matching user and system tables
\dfS pattern lists matching system tables only

\df lists user functions only
\dfS lists system functions only
\df pattern lists matching functions as per backend resolution
(search_path)
\dfS pattern lists matching system functions only, bypass search_path?

I think it's kind of easy to decline the concept, and I don't think
this will make unanimity. But what about dropping the consistency idea
(Tom is saying that it proved to be a damn bad one already) and from
there defining a usable tool?

Regards,
--
dim

On Mon, Mar 30, 2009 at 09:59:41PM +0200, Dimitri Fontaine wrote:
> Hi,
>
> Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
>> I think the big question is whether the inconsistency (pattern implies
>> 'S') is worth accepting for greater usability.
>
>
> My answer is yes, please, definitely, go for it.
> We don't need idiot-proof easy to remember semantics, we need useful
> ones... The former category is already taken care of by some other open
> source database software, have I been told...
>
> What about a mail with some content? Look, a user-level proposal draft!
> :)
> \dt lists user tables only
> \dtS lists system tables only

All of the S ones should probably mean, "include system objects"
rather than "only system objects."

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

On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > Maybe the best we are going to do is to have any pattern supplied to
> > > \d* assume 'S' (include system objects). ?I actually have a patch that
> > > does that, attached. (It is from January so might need adjustment.)
> >
> > That still has the problem that "\df a*" is horribly inconsistent with
> > "\df". It might be reasonable to assume that if a name without
> > wildcards is given to any \d command, it should display whatever
> > object it finds, user or system - but I can't see doing it for any
> > wildcard at all.
>
> I think you are re-iterating the URL I referenced when I started this
> thread:
>
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg01443.php
>
> I think the big question is whether the inconsistency (pattern implies
> 'S') is worth accepting for greater usability.
>

Actually I find the iconsistency to hurt usability, which is typically what
you get with inconsistent interfaces.

I'm not certain, but I think I would be happier if we did:

\d* user space objects
\d*S include system objects

For those that want system only, do
\d*S pg_catalog.
( if you want to argue temp/toast, adjust the search accordingly)

I think the trick to getting this working is to enforce this with search
patterns *and* tab completion as well. Yes, this means that Tom's desire for
sin has to become \dfS sin, but this maintains consistency (one of the issues
I've been running into is finding something via tab completion that I can't
actually see in the output listing, which is very annoying).

Further, should you create a function called sin and do \df sin, you should
only see your function. This can lead to confusion where you are calling a
built in function but you dont see it in \df, or you see a different function
in \df, but I haven't run into that case yet; in the work I've been doing in
8.4, the above is how I've been wanting it to work, and swapping to \df* to
see system hasn't been much of an issue.

BTW, I often do \df *.sin when looking for a function I'm not sure of where it
lives exactly; this being on current (<=8.3) releases, but many of the
systems involve a fair number of schemas, that might not be a common
practice, but perhaps should be.

--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com

Robert Treat wrote:
> On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> > Robert Haas wrote:
> > > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > > Maybe the best we are going to do is to have any pattern supplied to
> > > > \d* assume 'S' (include system objects). ?I actually have a patch that
> > > > does that, attached. (It is from January so might need adjustment.)
> > >
> > > That still has the problem that "\df a*" is horribly inconsistent with
> > > "\df". It might be reasonable to assume that if a name without
> > > wildcards is given to any \d command, it should display whatever
> > > object it finds, user or system - but I can't see doing it for any
> > > wildcard at all.
> >
> > I think you are re-iterating the URL I referenced when I started this
> > thread:
> >
> > http://archives.postgresql.org/pgsql-hackers/2009-01/msg01443.php
> >
> > I think the big question is whether the inconsistency (pattern implies
> > 'S') is worth accepting for greater usability.
> >
>
> Actually I find the iconsistency to hurt usability, which is typically what
> you get with inconsistent interfaces.
>
> I'm not certain, but I think I would be happier if we did:
>
> \d* user space objects
> \d*S include system objects

This is how CVS HEAD works now.

> For those that want system only, do
> \d*S pg_catalog.
> ( if you want to argue temp/toast, adjust the search accordingly)

Yep, same.

> I think the trick to getting this working is to enforce this with search
> patterns *and* tab completion as well. Yes, this means that Tom's desire for
> sin has to become \dfS sin, but this maintains consistency (one of the issues
> I've been running into is finding something via tab completion that I can't
> actually see in the output listing, which is very annoying).
> Further, should you create a function called sin and do \df sin, you should
> only see your function. This can lead to confusion where you are calling a
> built in function but you dont see it in \df, or you see a different function
> in \df, but I haven't run into that case yet; in the work I've been doing in
> 8.4, the above is how I've been wanting it to work, and swapping to \df* to
> see system hasn't been much of an issue.

I agree, Tom's case where he creates public.sin() is not going to show
without specifying public.sin. In fact Tom requested months ago that
psql follow the search_path in showing objects, so it is hard to see how
he can consider it wrong now.

> BTW, I often do \df *.sin when looking for a function I'm not sure of where it
> lives exactly; this being on current (<=8.3) releases, but many of the
> systems involve a fair number of schemas, that might not be a common
> practice, but perhaps should be.

The big question is whether '\d* pattern' should exclude looking for
system object, assuming search_path would show the system object, so
'\df cos' would show a function. I think usability supports this
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. +

Robert Treat wrote:
> Actually I find the inconsistency to hurt usability, which is typically what
> you get with inconsistent interfaces.
>
> I'm not certain, but I think I would be happier if we did:
>
> \d* user space objects
> \d*S include system objects
>
> For those that want system only, do
> \d*S pg_catalog.
> ( if you want to argue temp/toast, adjust the search accordingly)
>
> I think the trick to getting this working is to enforce this with search
> patterns *and* tab completion as well. Yes, this means that Tom's desire for

I talked to Robert on IM and found two new reasons to make 'S' assumed
if a pattern is supplied. The first is the use of tab completion:

test=> \df si<tab><tab>
sign similar_escape sin
test=> \df sin
List of functions
Schema | Name | Result data type | Argument data types
--------+------+------------------+---------------------
(0 rows)

As you can see tab-tab assumes system tables are visible, but current CVS
does not without 'S'. The second case is:

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

Only \dfS works in this case.

I think we should move forward and assume 'S' for \d* patterns; it is
inconsistent, but usability requires it.

Objections?

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

Attached patch applied, including documentation updates; I think this
is the best we are going to do to balance usability and consistency. I
have removed this as an open 8.4 item.

With this change \dfS and \df * do the same thing; I assume we don't
want to remove the 'S' modifier and tell people to just use '*', or
support '*' as the modifier instead of 'S', e.g. \df*.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Robert Treat wrote:
> > Actually I find the inconsistency to hurt usability, which is typically what
> > you get with inconsistent interfaces.
> >
> > I'm not certain, but I think I would be happier if we did:
> >
> > \d* user space objects
> > \d*S include system objects
> >
> > For those that want system only, do
> > \d*S pg_catalog.
> > ( if you want to argue temp/toast, adjust the search accordingly)
> >
> > I think the trick to getting this working is to enforce this with search
> > patterns *and* tab completion as well. Yes, this means that Tom's desire for
>
> I talked to Robert on IM and found two new reasons to make 'S' assumed
> if a pattern is supplied. The first is the use of tab completion:
>
> test=> \df si<tab><tab>
> sign similar_escape sin
> test=> \df sin
> List of functions
> Schema | Name | Result data type | Argument data types
> --------+------+------------------+---------------------
> (0 rows)
>
> As you can see tab-tab assumes system tables are visible, but current CVS
> does not without 'S'. The second case is:
>
> test=> \df pg_catalog.sin
> List of functions
> Schema | Name | Result data type | Argument data types
> --------+------+------------------+---------------------
> (0 rows)
>
> Only \dfS works in this case.
>
> I think we should move forward and assume 'S' for \d* patterns; it is
> inconsistent, but usability requires it.
>
> Objections?
>
> --
> 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. +
>
> --
> 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

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