From: | Dmitry Koterov <dmitry(at)koterov(dot)ru> |
---|---|
To: | Joel Jacobson <joel(at)gluefinance(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com> |
Subject: | Re: pg_dump --split patch |
Date: | 2011-01-03 12:11:33 |
Message-ID: | AANLkTi=oQC-NmqwcPXTds3MftPc4BVqBGsJv9-ANL-=S@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
To me, this is a wonderful feature, thanks! I think many people would be
happy if this patch woud be included to the mainstream (and it is quite
short and simple).
About name ordering - I think that the problem exists for objects:
1. Stored functions.
2. Foreign keys/triggers (objects which has owning objects).
It is wonderful that you store all functions with the same name to the same
file. To order them within this file we may simply compare the first
definition line lexicographically (or - first line which differs one
function definition from another).
Foreign key/triggers ordering problem is described by me at
http://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg114586.html
The big problem is with triggers: many triggers may have the same name, but
be bound to different tables. It would be great to include these triggers to
table's definition or, at least, have separated files for each trigger+table
pair.
On Wed, Dec 29, 2010 at 6:21 PM, Joel Jacobson <joel(at)gluefinance(dot)com> wrote:
> 2010/12/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>
>> I think they're fundamentally different things, because the previously
>> proposed patch is an extension of the machine-readable archive format,
>> and has to remain so because of the expectation that people will want
>> to use parallel restore with it. Joel is arguing for a split-up of
>> the text dump format.
>>
>>
> Yes, exactly.
>
> My patch is of course also a lot smaller :-)
> pg_dump-directory.diff.........................: 112 853 bytes
> pg-dump-split-plain-text-files-9.1devel.patch..: 5 579 bytes
>
> I just tried the pg_dump-directory.diff patch.
> The only thing is has in common with my patch is it writes data to
> different files, and it's only the data which is splitted into different
> files, the schema appears to go into the single file "TOC".
>
> Example, pg_dump-directory.diff:
>
> $ ./pg_dump -f /crypt/dirpatch -F d -s glue
> $ ls -la /crypt/dirpatch/
> TOC
> (1 file)
>
> $ rm -rf /crypt/dirpatch
>
> $ ./pg_dump -f /crypt/dirpatch -F d glue
>
> $ ls /crypt/dirpatch/
> 6503.dat
> 6504.dat
> ...lots of files...
> 6871.dat
> 6872.dat
> 6873.dat
> 6874.dat
> TOC
>
> Example, pg_dump --split patch:
>
> $ pg_dump -f /crypt/splitpatch -F p --split -s glue
>
> $ ls /crypt/splitpatch*
> /crypt/splitpatch (file)
> /crypt/splitpatch-split: (directory)
> myschema1
> myschema2
> public
> $ ls /crypt/splitpatch-split/public/
> AGGREGATE
> CONSTRAINT
> FK_CONSTRAINT
> FUNCTION
> INDEX
> SEQUENCE
> TABLE
> TRIGGER
> TYPE
> VIEW
>
> $ ls /crypt/splitpatch-split/public/FUNCTION/
> myfunc.sql
> otherfunc.sql
>
> $ cat /crypt/splitpatch
> --
> -- PostgreSQL database dump
> --
>
> SET statement_timeout = 0;
> SET client_encoding = 'UTF8';
> SET standard_conforming_strings = off;
> SET check_function_bodies = false;
> SET client_min_messages = warning;
> SET escape_string_warning = off;
> ...etc...
> \i /crypt/splitpatch-split/public/FUNCTION/myfunc.sql
> \i /crypt/splitpatch-split/public/FUNCTION/otherfunc.sql
>
>
> --
> Best regards,
>
> Joel Jacobson
> Glue Finance
>
From | Date | Subject | |
---|---|---|---|
Next Message | JotaComm | 2011-01-03 12:54:31 | Re: Problems with autovacuum and vacuum |
Previous Message | Magnus Hagander | 2011-01-03 11:55:21 | Re: Libpq PGRES_COPY_BOTH - version compatibility |