Re: SHOW TABLES

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: SHOW TABLES
Дата
Msg-id 71383B90-070C-4E56-A78C-3BBCCAC0108B@hi-media.com
обсуждение исходный текст
Ответ на Re: SHOW TABLES  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
Le 16 juil. 2010 à 18:42, Kevin Grittner a écrit :
> Like \d, these server-side stored procedures can return a number of
> result sets.  Like Robert, I'm skeptical of implementing a
> server-side solution for PostgreSQL which doesn't do the same.  I'm
> not clear on whether that's even possible without a new version of
> wire protocol, though.

Well, I think we shouldn't mix it all. My view on that is that we need some easy simple commands in the backend, none
ofthem on its own would mimic \d. 

Consider this psql command: psql -E -c '\d'. What I think is that each query you see there could easily become a SHOW
subsyntax(from memory, we probably would have SHOW TABLE, SHOW INDEXES ON <table>, SHOW TRIGGERS ON <table>, SHOW
CONSTRAINTSON <table>, etc). 

Now, psql would be free to implement its \d in terms of those new queries rather than the full SQL ones it has now,
thatwould be a good first client. Oh and that means the design is about all done already. And that we still are in the
onecommand - one resultset interface. Meaning any libpq driver knows how to deal with the resultset, and that's not
parsingtext. 

I'm all with Simon here, it's not about offering any new capability that we don't already have, it's about having it
handyfrom anywhere. So let's just have an easy syntax in the backend to do all the catalog 'magic' querying psql does,
butone query at a time. 

Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte







В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: log files and permissions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock