Re: pg_dump new feature: exporting functions only. Bad or good idea ? - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: pg_dump new feature: exporting functions only. Bad or good idea ?
Date
Msg-id 269300d1-24c9-5bf2-9fad-812f89ed0091@enterprisedb.com
Whole thread Raw
In response to Re: pg_dump new feature: exporting functions only. Bad or good idea ?  (ahsan hadi <ahsan.hadi@gmail.com>)
Responses Re: pg_dump new feature: exporting functions only. Bad or good idea ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

I took a quick look at the patch today. There was some minor bitrot
requiring a rebase, so I attach the rebased patch as v3.

The separate 0002 part contains some minor fixes - a couple
typos/rewording in the docs (would be good if a native speaker looked at
it, thought), and a slightly reworked chunk of code from pg_dump.c. The
change is more a matter of personal preference than correctness - it
just seems simpler this way, but ymmv. And I disliked that the comment
said "If we have to export only the functions .." but the if condition
was actually the exact opposite of that.

The main question I have is whether this should include procedures. I'd
probably argue procedures should be considered different from functions
(i.e. requiring a separate --procedures-only option), because it pretty
much is meant to be a separate object type. We don't allow calling DROP
FUNCTION on a procedure, etc. It'd be silly to introduce an unnecessary
ambiguity in pg_dump and have to deal with it sometime later.

I wonder if we should allow naming a function to dump, similarly to how
--table works for tables, for example.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: Pre-allocating WAL files
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Pull general SASL framework out of SCRAM