On 13-01-24 05:43 AM, Dimitri Fontaine wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
>> <dimitri@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.
