On 13-01-24 05:43 AM, Dimitri Fontaine wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
<dimi...@2ndquadrant.fr> wrote:
- Context exposing and filtering
I'm not feeling very sanguine about any of this. I feel strongly that
we should try to do something that's more principled than just
throwing random junk into ProcessUtility.
The goal is to allow for advanced users of that feature to get at the
sequence, constraints and index names that have been picked
automatically by PostgreSQL when doing some CREATE TABLE statement that
involves them:
CREATE TABLE foo (id serial PRIMARY KEY, f1 text);
Andres and Steve, as you're the next ones to benefit directly from that
whole feature and at different levels, do you have a strong opinion on
whether you really need that to operate at the logical level?
I haven't been following this thread very closely and I'm not exactly
sure what your asking.
If the question is what a replication system would need to replicate DDL
commands, then I need a method of translating whatever the DDL trigger
is passed into either the 'CREATE TABLE public.foo(id serial primary
key, f1 text)' OR some set of equivalent commands that will allow me to
create the same objects on the replica. I don't have any brilliant
insight on how I would go about during it. Honestly I haven't spent a
lot of time thinking about it in the past 8 months.
If your asking what I would need for a trigger to automatically add a
new table to replication then I think I would only need to know (or be
able to obtain) the fully qualified name of the table and then in
another trigger call be given the name of the fully qualified name of
the sequence. The triggers would need to be able to do DML to
configuration tables. I don't need to know that a table and sequence
are connected if all I want to do is replicate them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
