From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ToDo: pg_backup - using a conditional DROP |
Date: | 2011-11-15 18:53:33 |
Message-ID: | m2ehx98bf6.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I wonder if that instead of trying to remain "somewhat compatible" to
>> other systems we should instead have a mode specifically designed for
>> that --one which didn't output SET or backslash commands, used inserts
>> rather than COPY, etc-- and have the noncompatible mode offer nice
>> features such as DROP IF EXISTS and the like.
>
> mysqldump has a --compatible=OTHER_DB_SYSTEM flag (postgresql is one
> of the choices). That might not be a crazy way to approach the
> problem, though possibly we'd want --compatible=FOO to be a shorthand
> for a collection of behaviors that could alternatively be selected
> individually via appropriately named long options
> (--no-backslash-commands, --no-set-commands, etc.).
I can't help but recalling Hannu's lightning talk at pgconf.eu in
Amsterdam last month. What about implementing mysql protocol and syntax
instead, so that users would just use mysqldump here, if that's the
format they do want to play with.
Not the same scale of work, but opening our infrastructure to multiple
syntaxes and protocols could be something to aim for. Think memcache
protocol backed by hstore or even plv8, too.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2011-11-15 18:55:14 | Re: [PATCH] Unremovable tuple monitoring |
Previous Message | Kevin Grittner | 2011-11-15 18:52:27 | Re: Core Extensions relocation |