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  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: EDB builds Postgres 13 with an obsolete ICU version