Thread: psql's \d commands --- end of the line for 1-character identifiers?
[ 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
Re: psql's \d commands --- end of the line for 1-character identifiers?
From
"Christopher Kings-Lynne"
Date:
> ... 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, Pennsylvania19073
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"
> >"\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?
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 |/
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
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
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
> > 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
> > 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
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
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