It seems that the best way to handle \d is the way many database vendors
do it: through an SQl statement:
In informix, it's INFO command, in RDB is is SHOW...
Something like INFO TABLE; would list all tables,
INFO TABLE sometablename would display info for one table...
INFO INDEX, INFO SEQUENCE....etc...
But I suppose stripping ';' from the end of \d command would be ok..
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Sun, 29 Jun 1997, Bruce Momjian wrote:
> >
> > Bruce Momjian writes ("Re: [HACKERS] Case sensitivity in identifiers"):
> > > > Right now saying '\d FOO' says 'Couldn't find table FOO!' so somebody
> > > > missed a bit of case-sensitivity code somewhere, but I'm sure you see
> > >
> > > I will check on this. Looks like a bug.
> >
> > Cheers. Incidentally I wish \d tablename wouldn't complain if I stuck
> > a ; on the end, just because I get in to the habit inside psql, but I
> > know the ; is only supposed to terminate SQL statements which \d isn't.
>
> I do the same thing. Would anything break if I removed a trailing ';'
> from \d commands? Anyone?
>
> >
> > > You have a good point here. I can see a value in keeping case when
> > > creating fields, but allowing any case to access it. Is that the basis
> > > of the argument.
> >
> > Yes indeed.
> >
> > > Right now, we lowercase arguments when the come in from the parser. We
> > > could preserve case for Create-type statements, and force lowercase on
> > > all comparisons, but that is a big job, and I think we questioned the
> > > value of it.
> >
> > I wouldn't have thought it was a particularly big job; you keep these
> > identifiers in postgres tables anyway: why not a new batch of char
> > types and operators using strcasecmp instead of strcmp?
> >
> > I'm suggesting that's not a big job because if you've structured your
> > code right (of course you have!) you just copy all the files, do a
> > spot of search and replace, and possibly some minor tweaking. Maybe
> > even just two new functions (compare ignoring case - or don't you have
> > it already?) plus a suite of case-insensitive character operators to
> > sort out indexing.
> >
> > Some end users might even find such new functionality useful...
>
> It is not that easy. We use indexes and cached keys to look up things.
> Doing such things case-insensitive is a big job.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>
------------------------------
