Re: use pg_get_functiondef() in pg_dump
| От | Corey Huinker |
|---|---|
| Тема | Re: use pg_get_functiondef() in pg_dump |
| Дата | |
| Msg-id | CADkLM=fEwFk0Orhcxx7grFCQxFZUVRZxAynZNUJjk3uMz=G-EQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: use pg_get_functiondef() in pg_dump (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: use pg_get_functiondef() in pg_dump
|
| Список | pgsql-hackers |
I'm sure there's a lot of folks who'd like to see more of the logic we
have in pg_dump for building objects from the catalog available to more
tools through libpgcommon- psql being one of the absolute first
use-cases for exactly that (there's certainly no shortage of people
who've asked how they can get a CREATE TABLE statement for a table by
using psql...).
I count myself among those folks (see https://www.postgresql.org/message-id/CADkLM%3DfxfsrHASKk_bY_A4uomJ1Te5MfGgD_rwwQfV8wP68ewg%40mail.gmail.com for discussion of doing DESCRIBE and SHOW CREATE-ish functions either on server side or client side).
I'm all for having this as "just" as set of pg_get_*def functions, because they allow for the results to be used in queries. Granted, the shape of the result set may not be stable, but that's the sort of thing we can warn for the same way we have warnings for changes to pg_stat_activity. At that point any DESCRIBE/SHOW CREATE server side functions essentially become just shells around the pg_get_*def(), with no particular requirement to make those new commands work inside a SELECT.
Would it be totally out of left field to have the functions have an optional "version" parameter, defaulted to null, that would be used to give backwards compatible results if and when we do make a breaking change?
В списке pgsql-hackers по дате отправления: