Re: [HACKERS] Are we losing momentum? - Mailing list pgsql-patches
From | Sean Chittenden |
---|---|
Subject | Re: [HACKERS] Are we losing momentum? |
Date | |
Msg-id | 20030417194803.GU79923@perrin.int.nxad.com Whole thread Raw |
In response to | Re: [HACKERS] Are we losing momentum? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [HACKERS] Are we losing momentum?
|
List | pgsql-patches |
> >> 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
pgsql-patches by date: