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

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

[ 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

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

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>

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

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

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

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

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"

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

"\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?

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

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>

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

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

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

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

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