Re: use pg_get_functiondef() in pg_dump - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: use pg_get_functiondef() in pg_dump
Date
Msg-id CADkLM=fEwFk0Orhcxx7grFCQxFZUVRZxAynZNUJjk3uMz=G-EQ@mail.gmail.com
Whole thread Raw
In response to Re: use pg_get_functiondef() in pg_dump  (Stephen Frost <sfrost@snowman.net>)
Responses Re: use pg_get_functiondef() in pg_dump  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Next
From: Michael Paquier
Date:
Subject: Re: EDB builds Postgres 13 with an obsolete ICU version