Re: Porting from MySql - meta data issues
От
Gregory Wood
Тема
Re: Porting from MySql - meta data issues
Дата
Msg-id
013901c1df16$221bb400$7889ffcc@comstock.com
Список
Дерево обсуждения
Porting from MySql - meta data issues Geoff Caplan <geoff@advantae.com>
Re: Porting from MySql - meta data issues Jeff Eckermann <jeff_eckermann@yahoo.com>
Re: Porting from MySql - meta data issues Geoff Caplan <geoff@advantae.com>
Re: Porting from MySql - meta data issues Alvaro Herrera <alvherre@atentus.com>
Re: Porting from MySql - meta data issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Porting from MySql - meta data issues Jean-Michel POURE <jm.poure@freesurf.fr>
> > You can also use the pg_tables view, for example, and the system > > catalogs for the rest (pg_database, pg_attribute). > > > Anyway, there's little use for SHOW queries, as you can always poke into > > the system catalogs. That's something you can't do in MySQL, and is the > > reason for the SHOW hack. > > If we actually implement anything new in this line, it will presumably > be the SQL-standard-compliant INFORMATION_SCHEMA views. Although as > far as I can see, those have nothing to recommend them except standards > compliance :-(. "SELECT * FROM INFORMATION_SCHEMA.TABLES" doesn't seem > to have any great advantage over either "\d" or whatever the equivalent > MySQL SHOW command is... Except that it's awfully hard to do a "\d" if you're not in psql. To get a list of tables I had to use "psql -E" to figure out the query so that I could perform the query myself. The real advantage of a view to me would be if any changes are made to the system catalog that would 'break' the query, it would be handled transparently by changing the view. Greg
В списке pgsql-general по дате отправления