Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I wrote:
> > I wouldn't say that it's *fundamentally* new, but nonethless it disturbs
> > me that this proposal has pg_dump assembling CREATE FUNCTION commands in
> > very different ways depending on the server version. I'd rather see us
> > continuing to build the bulk of the command the same as before, and
> > introduce new behavior only for deparsing the function body.
>
> BTW, a concrete argument for doing it that way is that if you make a
> backend function that does the whole CREATE-FUNCTION-building job in
> exactly the way pg_dump wants it, that function is nigh useless for
> any other client with slightly different requirements. A trivial
> example here is that I don't think we want to become locked into
> the proposition that psql's \ef and \sf must print functions exactly
> the same way that pg_dump would.
The fact that the need that psql has and that which pg_dump has are at
least somewhat similar really argues that we should have put this code
into libpgcommon in the first place and not in the backend, and then had
both psql and pg_dump use that.
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...).
Thanks,
Stephen