(Doh!  Forgot to attach first time.)

This partially nails this TODO item:

* Add schema, cast, and conversion backslash commands to psql

I had to create a new publically available function,
pg_conversion_is_visible, as it seemed to be missing from the catalogs.
This required me to do no small amount of hacking around in namespace.c

I have updated the \? help and sgml docs.

\dc - list conversions [PATTERN]
\dC - list casts

I didn't support patterns with casts as there's nothing obvious to match
against.

I've tested it a fair bit and I can't see any problems.  Feel free to do a
once over on my backend changes tho.

Chris
Sun, 8 Dec 2002 20:39:11 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
show casts and conversions in psql (2nd try)
Christopher Kings-Lynne writes:

> \dc - list conversions [PATTERN]
> \dC - list casts

What are we going to use for collations?

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 9 Dec 2002 20:48:55 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: show casts and conversions in psql (2nd try)


> Christopher Kings-Lynne writes:
> 
> > \dc - list conversions [PATTERN]
> > \dC - list casts
> 
> What are we going to use for collations?

\dn   Is the only letter left in collations that hasn't been used!

Chris


Mon, 9 Dec 2002 12:10:24 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: show casts and conversions in psql (2nd try)
[ moved to hackers from pgsql-patches ]

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Peter wrote:
>> Christopher Kings-Lynne writes:
>>> \dc - list conversions [PATTERN]
>>> \dC - list casts
>> 
>> What are we going to use for collations?

> \dn   Is the only letter left in collations that hasn't been used!

... and that was already proposed for "show schemas" (namespaces).

I'm inclined to think it's time to bite the bullet and go over to
words rather than single characters to identify the \d target
(viz, "\dschema", "\dcast", etc, presumably with unique abbreviations
being allowed, as well as special cases for the historical single
characters).

The issue here is what do we do with the existing "\d[istvS]" behavior
(for instance, "\dsit" means "list sequences, indexes, and tables").
Is that useful enough to try to preserve, or do we just bit-bucket it?
If we do try to preserve it, how should it work?

			regards, tom lane

Mon, 09 Dec 2002 16:05:43 -0500
Tom Lane <tgl@sss.pgh.pa.us>
psql's \d commands --- end of the line for 1-character identifiers?
> ... and that was already proposed for "show schemas" (namespaces).
>
> I'm inclined to think it's time to bite the bullet and go over to
> words rather than single characters to identify the \d target
> (viz, "\dschema", "\dcast", etc, presumably with unique abbreviations
> being allowed, as well as special cases for the historical single
> characters).

Hmmm...I'm not certain that the \d commands really NEED to have a logical
link to the actual thing you're listing.  If you just made \dh for schemas,
people would look it up and then remember it from then on.  It's probably
not a huge deal.

We could do DESCRIBE commands as well.  Also, what happened to the
INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
What happened to it?

> The issue here is what do we do with the existing "\d[istvS]" behavior
> (for instance, "\dsit" means "list sequences, indexes, and tables").
> Is that useful enough to try to preserve, or do we just bit-bucket it?
> If we do try to preserve it, how should it work?

I'd much rather it were preserved, and I'm sure most people would as well.

Chris


Mon, 9 Dec 2002 13:22:20 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: psql's \d commands --- end of the line for 1-character
	identifiers?
Tom Lane kirjutas T, 10.12.2002 kell 02:05:
> [ moved to hackers from pgsql-patches ]
> 
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > Peter wrote:
> >> Christopher Kings-Lynne writes:
> >>> \dc - list conversions [PATTERN]
> >>> \dC - list casts
> >> 
> >> What are we going to use for collations?
> 
> > \dn   Is the only letter left in collations that hasn't been used!
> 
> ... and that was already proposed for "show schemas" (namespaces).
> 
> I'm inclined to think it's time to bite the bullet and go over to
> words rather than single characters to identify the \d target
> (viz, "\dschema", "\dcast", etc, presumably with unique abbreviations
> being allowed, as well as special cases for the historical single
> characters).
> 
> The issue here is what do we do with the existing "\d[istvS]" behavior
> (for instance, "\dsit" means "list sequences, indexes, and tables").
> Is that useful enough to try to preserve, or do we just bit-bucket it?
> If we do try to preserve it, how should it work?

Why not use \D for "long" ids ?

Somewhat similar to -? and --help for command line.

-- 
Hannu Krosing <hannu@tm.ee>

10 Dec 2002 02:25:12 +0500
Hannu Krosing <hannu@tm.ee>
Re: psql's \d commands --- end of the line for
Hannu Krosing <hannu@tm.ee> writes:
> Why not use \D for "long" ids ?

Seems like a fine idea to me.  (I had actually started to think of
"\s<something>" for "show", but was just observing that that would
create conflicts against existing commands, when your message arrived.
"\D<something>" works though.)

Any objections out there?

			regards, tom lane

Mon, 09 Dec 2002 17:13:02 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql's \d commands --- end of the line for 
At 05:13 PM 9/12/2002 -0500, Tom Lane wrote:
>Seems like a fine idea to me.

Ditto.

>"\D<something>" works though.)
>
>Any objections out there?

My only complaint here is being forced to use the 'shift' key on commands 
that will be common. I would prefer any other lower case char: \b, \j, \k , 
\m, \n,   \u, \v, and \y are available. I'd vote for \v (view), or \k 
(command). The go with:

     \v schema
or
     \k show schema

(I'd vote for \v).







----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                  |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Tue, 10 Dec 2002 10:12:31 +1100
Philip Warner <pjw@rhyme.com.au>
Re: psql's \d commands --- end of the line for 
Christopher Kings-Lynne wrote:
> We could do DESCRIBE commands as well.  Also, what happened to the
> INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
> What happened to it?
> 
> > The issue here is what do we do with the existing "\d[istvS]" behavior
> > (for instance, "\dsit" means "list sequences, indexes, and tables").
> > Is that useful enough to try to preserve, or do we just bit-bucket it?
> > If we do try to preserve it, how should it work?
> 
> I'd much rather it were preserved, and I'm sure most people would as well.

I was going to say the opposite, that it isn't needed.  Oh well.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 9 Dec 2002 20:36:49 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql's \d commands --- end of the line for 1-character
At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote:
>Hmmm...I'm not certain that the \d commands really NEED to have a logical
>link to the actual thing you're listing.

This is the perspective a person with good memory, unlike me. In find it 
useful to be able to derive commands from common-sense rules, even if it 
means a little more typing.


>We could do DESCRIBE commands as well.  Also, what happened to the

This would be fine, so long as the standard does not get in the way of 
displaying postgres-specific information (eg. function attrs).


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                  |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Tue, 10 Dec 2002 12:55:51 +1100
Philip Warner <pjw@rhyme.com.au>
Re: psql's \d commands --- end of the line for
On Tue, Dec 10, 2002 at 12:55:51PM +1100, Philip Warner wrote:
> At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote:
> >Hmmm...I'm not certain that the \d commands really NEED to have a logical
> >link to the actual thing you're listing.
> 
> This is the perspective a person with good memory, unlike me. In find it 
> useful to be able to derive commands from common-sense rules, even if it 
> means a little more typing.

Would it work to make \d tab-completable in a way that showed both the
commands that are available and the objects they describe? e.g.

\d<tab> would show something like
\dt [tables]	\ds [sequences]	\dv [views] ...

(the way it's shown now shows what completions are available, but not
what they mean.  Also, both \d and \D should be shown in any case)

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Los romanticos son seres que mueren de deseos de vida"

Tue, 10 Dec 2002 01:55:38 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: psql's \d commands --- end of the line for
At 01:55 AM 10/12/2002 -0300, Alvaro Herrera wrote:
>\d<tab> would show something like
>\dt [tables]    \ds [sequences] \dv [views] ...
>
>(the way it's shown now shows what completions are available, but not
>what they mean.  Also, both \d and \D should be shown in any case)

This would be OK, but I'd be very happy with DESCRIBE, especially if 
tab-completion meant I could type 'DESC<tab>TAB<tab><name>' instead of 
'DESCRIBE TABLE <name>'.



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                  |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Tue, 10 Dec 2002 17:16:26 +1100
Philip Warner <pjw@rhyme.com.au>
Re: psql's \d commands --- end of the line for
> >"\D<something>" works though.)
> >
> >Any objections out there?
>
> My only complaint here is being forced to use the 'shift' key on commands
> that will be common.

\dd perhaps?


Tue, 10 Dec 2002 00:18:12 -0600
"Matthew T. O'Connor" <matthew@zeut.net>
Re: psql's \d commands --- end of the line for 
Philip Warner <pjw@rhyme.com.au> writes:
> This would be OK, but I'd be very happy with DESCRIBE, especially if 
> tab-completion meant I could type 'DESC<tab>TAB<tab><name>' instead of 
> 'DESCRIBE TABLE <name>'.

That's quicker than <backslash><shift><D><unshift><t><space><name> ?

I don't want to sound like I've got some kind of religious objection
to DESCRIBE, but it was just a couple of hours ago that someone was
objecting to "\D" because it'd require touching the shift key.  Let's
get a bit realistic on the ease-of-typing arguments here.

			regards, tom lane

Tue, 10 Dec 2002 01:25:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql's \d commands --- end of the line for 
On Mon, 2002-12-09 at 23:12, Philip Warner wrote:
> At 05:13 PM 9/12/2002 -0500, Tom Lane wrote:
> >Seems like a fine idea to me.
> 
> Ditto.
> 
> >"\D<something>" works though.)
> >
> >Any objections out there?
> 
> My only complaint here is being forced to use the 'shift' key on commands 
> that will be common.

On most european keyboards you alreday have to use "AltGr" to get to \
so using an extra shift is not too bad ;)


-- 
Hannu Krosing <hannu@tm.ee>

10 Dec 2002 17:05:42 +0000
Hannu Krosing <hannu@tm.ee>
Re: psql's \d commands --- end of the line for


> At 01:25 AM 10/12/2002 -0500, Tom Lane wrote:
> >Let's
> >get a bit realistic on the ease-of-typing arguments here.
>
> It's a fair cop, but don't forget the memory argument as well - I did say
I
> was happy with \d<tab> providing prompts, and DESCRIBE is a little more
> portable & memorable than \d[heiroglyphic].

I think the problem with DESCRIBE is that it's supposed to just return a
recordset.  I don't see it showing fk's, indexes, rules, etc. as well...

Chris


Tue, 10 Dec 2002 11:47:04 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: psql's \d commands --- end of the line for 
Peter Eisentraut <peter_e@gmx.net> writes:
> Christopher Kings-Lynne writes:
>> We could do DESCRIBE commands as well.  Also, what happened to the
>> INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
>> What happened to it?

> Ooops.  Yeah, let's get this in.  Where should I put it?

How do you mean "where"?  The spec says it's gotta be called
information_schema, no?  What's left to decide?

			regards, tom lane

Tue, 10 Dec 2002 15:03:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql's \d commands --- end of the line for 1-character
	identifiers?
Alvaro Herrera writes:

> Would it work to make \d tab-completable in a way that showed both the
> commands that are available and the objects they describe? e.g.
>
> \d<tab> would show something like
> \dt [tables]	\ds [sequences]	\dv [views] ...

That won't work.  The actual completion and the view of the alternatives
if the completion is ambiguous is driven by the same data.

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 10 Dec 2002 21:04:07 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql's \d commands --- end of the line for
Christopher Kings-Lynne writes:

> We could do DESCRIBE commands as well.  Also, what happened to the
> INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
> What happened to it?

Ooops.  Yeah, let's get this in.  Where should I put it?

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 10 Dec 2002 21:04:59 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql's \d commands --- end of the line for 1-character
	identifiers?
> > We could do DESCRIBE commands as well.  Also, what happened to the
> > INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
> > What happened to it?
>
> Ooops.  Yeah, let's get this in.  Where should I put it?

I wouldn't mind having a look at the patch.  Where do you implement this
kind of thing?  Where in the code do you create system views and schemas?
Just add to the initdb script or something?

Adding this should allow us to move around 20 items from the sql99
unsupported list to the supported, which would be sweet.

Chris


Tue, 10 Dec 2002 13:51:10 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
INFORMATION_SCHEMA
> > We could do DESCRIBE commands as well.  Also, what happened to the
> > INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
> > What happened to it?
>
> Ooops.  Yeah, let's get this in.  Where should I put it?

I wouldn't mind having a look at the patch.  Where do you implement this
kind of thing?  Where in the code do you create system views and schemas?
Just add to the initdb script or something?

Adding this should allow us to move around 20 items from the sql99
unsupported list to the supported, which would be sweet.

Chris


Tue, 10 Dec 2002 13:51:45 -0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
INFORMATION_SCHEMA

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

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


Christopher Kings-Lynne wrote:
> (Doh!  Forgot to attach first time.)
> 
> This partially nails this TODO item:
> 
> * Add schema, cast, and conversion backslash commands to psql
> 
> I had to create a new publically available function,
> pg_conversion_is_visible, as it seemed to be missing from the catalogs.
> This required me to do no small amount of hacking around in namespace.c
> 
> I have updated the \? help and sgml docs.
> 
> \dc - list conversions [PATTERN]
> \dC - list casts
> 
> I didn't support patterns with casts as there's nothing obvious to match
> against.
> 
> I've tested it a fair bit and I can't see any problems.  Feel free to do a
> once over on my backend changes tho.
> 
> Chris

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 10 Dec 2002 22:47:04 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: show casts and conversions in psql (2nd try)
Tom Lane writes:

> How do you mean "where"?  The spec says it's gotta be called
> information_schema, no?  What's left to decide?

I was more wondering where in the source tree to put and how to install
it.  I would suggest the following:  I have a file information_schema.sql
which contains the commands to create the information schema in a
user-space manner.  I'd put it into backend/catalog, from there it gets
installed in the same place the .bki files go, and initdb installs it into
template1 near the end.

Maybe someone wants to make a case for putting the information schema
definitions into a bunch of separate .sql files, one for each item defined
in the standard?

We also have to think whether we want to magically represent the
information_schema in the search path as the spec prescribes.  I would
suggest a "no" for that.  The names of the objects in the information
schema are way to obvious to put in the default namespace (pun intended
for amusement).

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 11 Dec 2002 20:57:12 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql's \d commands --- end of the line for 1-character
	identifiers?
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> How do you mean "where"?

> I was more wondering where in the source tree to put and how to install
> it.  I would suggest the following:  I have a file information_schema.sql
> which contains the commands to create the information schema in a
> user-space manner.  I'd put it into backend/catalog, from there it gets
> installed in the same place the .bki files go, and initdb installs it into
> template1 near the end.

Ah.  That works for me.

> Maybe someone wants to make a case for putting the information schema
> definitions into a bunch of separate .sql files, one for each item defined
> in the standard?

One file per item is way overkill ... especially when there's no obvious
reason that people would want some but not all of these items.

> We also have to think whether we want to magically represent the
> information_schema in the search path as the spec prescribes.

We already have the necessary mechanism to let this be set on a
per-installation (or even per-database or per-user) basis.  I agree with
your thought that we need not make it the factory default.

			regards, tom lane

Wed, 11 Dec 2002 23:14:43 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql's \d commands --- end of the line for 1-character
	identifiers?

This is the patch description.

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

Christopher Kings-Lynne wrote:
> (Doh!  Forgot to attach first time.)
> 
> This partially nails this TODO item:
> 
> * Add schema, cast, and conversion backslash commands to psql
> 
> I had to create a new publically available function,
> pg_conversion_is_visible, as it seemed to be missing from the catalogs.
> This required me to do no small amount of hacking around in namespace.c
> 
> I have updated the \? help and sgml docs.
> 
> \dc - list conversions [PATTERN]
> \dC - list casts
> 
> I didn't support patterns with casts as there's nothing obvious to match
> against.
> 
> I've tested it a fair bit and I can't see any problems.  Feel free to do a
> once over on my backend changes tho.
> 
> Chris

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 12 Dec 2002 16:03:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: show casts and conversions in psql (2nd try)