Re: [HACKERS] Are we losing momentum?
От | Rod Taylor |
---|---|
Тема | Re: [HACKERS] Are we losing momentum? |
Дата | |
Msg-id | 1054436929.11968.77.camel@jester обсуждение исходный текст |
Ответ на | Re: [HACKERS] Are we losing momentum? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
> It would also be interesting to combine this with Rod's idea of driving > describe-type queries by table instead of hardwired code. Imagine that > the backend's "show foo" command first looks for "foo" as a GUC > variable, as it does now, but upon failing to find one it looks in a > system table for a query associated with the name "foo". If it finds > such a query, it runs it and sends back the result. Now, not only can > we emulate "show tables", but people can easily add application-specific > "show whatever" commands, which seems tremendously cool. Easy enough to accomplish for the most part. I suppose the most difficult part is whether we support arbitrary syntax? SHOW INDEXES ON TABLE <bleah>; SHOW TABLES; SHOW DATABASES; SHOW COLUMNS FROM <table>; <-- Long form of DESCRIBE <table> I believe all of the above is valid MySQL syntax, so we would need to be able to work with a list of colId, rather than a single one. This does not help with tab completion or help for the above items. Though one could certainly argue help on available commands should come from the backend, and psql could be taught how to read the table to determine how to deal with tab completion. One significant downside is that describe commands would require an initdb when updated. Oh, if it's the backend doing the work, the queries should probably be functions, not free-form queries. Simply makes it easier to inject variables into the right place. In the initial patch, psql is using a prepared statement for this work with the side benefit that the plan is cached. An SQL function would accomplish the same thing. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Вложения
В списке pgsql-patches по дате отправления: