Re: [HACKERS] Are we losing momentum?

> >> I don't think these should be hacked into the backend/libpq, but
> >> I think it'd be a huge win to hack in "show *" support into psql
> >> for MySQL users so they can type:
> >>
> >> SHOW (databases|tables|views|functions|triggers|schemas);
>
> > Well, we (will) have the information schema, and if you like you
> > can put it in the path and write select * from tables; etc., which
> > seems just as good.

I thought about changing the SHOW commands to executing a SELECT from
the information_schema schema, actually, but unless the various \d
commands are going to get switched to SELECT'ing from the
information_schema, it decreases the likelihood that someone will
successfully switch over to using the \d commands in psql.  I believe
that the \d commands are a good thing and it's good that the backend
doesn't have support for the \d commands.  Having \d or SHOW commands
in the backend would dirty up the sources of the backend, IMHO.

> I think Sean's idea is not to make it "just as easy as MySQL", it's
> to make it "the *same* as MySQL", for the benefit of those that
> refuse to learn differently.  Them as won't adjust to "\dt" in place
> of "show tables" aren't likely to adjust to "select * from tables"
> either.  Not even (maybe especially not) if it's arguably a
> standard.

It's amazing what you can accomplish by taking out your DBAs and
racking up a $20 bar tab (note to would be attempters of this method:
when the bar tab gets to $50, you find out things you didn't really
want to know or weren't intending to hear).  So yeah, as Tom said,
they know \d [table_name], I've been able to get that much through,
but syntactically, it doesn't offer the same syntactic goo that their
fingers are used to typing and they _hate_ that there's no SHOW
command for tables.  It's a usability irk that kills them every time,
they type "SHOW [tab]" him.  There are a few other things I picked up
that evening too.

*) MySQL's CLI tab completion is terrible and the SHOW commands work
   even worse than other tab operations in mysql, this _is_ something
   that they do like about psql.  psql's tab completion is really
   snappy by comparison.

*) The _only_ time that they use the SHOW commands is when they're
   using a CLI.

So as opposed to supporting MySQL's brokenness, I hacked a small
parser into psql and added a TIP to the top of the result set printed
to stderr that tells the user how to use the equiv \d command.

> I think the idea has some merit; although I wonder whether it
> wouldn't be smarter to put the code in the backend so that you don't
> need a parser in psql.  The SHOW code could fall back to looking at
> these possibilities after it fails to find a match to a GUC variable
> name.

Well, I think that the backend should be kept clean of MySQL's
nastiness.  It's ugly to have a small parser in psql, but I think it's
better off than letting MySQL dictate non-existent standards to the
rest of the DB community because its developers have struck a chord
with the newbie database masses.  PostgreSQL is a better database, we
shouldn't have to cater to their hackery.  -sc

--
Sean Chittenden