Re: How to individually list the DDL for all individual data base objects

On 11/24/2014 08:12 AM, Berend Tober wrote:
> François Beausoleil wrote:
>>
>> Le 2014-11-24 à 10:14, Berend Tober <btober@broadstripe.net> a écrit :
>>
>>> Is there a good way to individually list the DDL for all individual
>>> data base objects?
>>>
>>
>> <snip>
>>
>>
>> Were you aware that pg_restore can restore to STDOUT, and output DDL
>> for only a single named object from a custom dump file?
>
> Yes sir, thank you. That is what the script does.
>
> But that little script seems fragilly-dependent upon the format of the
> list file and runs (starts a new process for) pg_restore for every
> individual line in the list file. ... which seems like poor practise,
> generally. Additionally, I'd like stability in the output file names,
> rather than the (likely changing) internal, automatically
> numerically-named items.
>
> And, btw, I want not just a single table.
>
> The dependance issue is potentially a problem, but (as I believe) it
> looks like the output of pg_restore in a list file is in the correct
> order to process dependencies, so I could walk backwards of forwards
> through that if changes to one object were dependent on, or caused
> cascading effects in other objects.

At this point I have to ask:

What is the problem you are trying to solve?

Your last paragraph seems to be reinventing the -Fc TOC, so I am not
sure where you going with this?

>
>
>
>>
>> $ pg_restore —help
>> …
>>
>>    -f, --file=FILENAME      output file name
>> …
>>    -t, --table=NAME         restore named table
>> …
>>
>> Such that you could run:
>>
>> $ pg_restore -f public.mytable.sql -t public.mytable whatever.pgdump
>>
>> Unfortunately, this does not respect dependencies and you may have
>> issues. The --disable-triggers option can alleviate some of these
>> problems. YMMV.
>>
>> Hope that helps!
>> François
>>
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com