Re: Event Triggers: adding information

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Event Triggers: adding information
Дата
Msg-id 10183.1358531053@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Event Triggers: adding information  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Event Triggers: adding information  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
>> I'm having trouble following this.  Can you restate?  I wasn't sure
>> what you meant by libpqdump.  I assumed you were speaking of a
>> parsetree->DDL or catalog->DDL facility.

> Yea, that wasn't really clear, sorry for that.

> What I was trying to say that I think doing parstree->text conversion
> out of tree is noticeably more complex and essentially places a higher
> maintenance burden on the project because

Ah.  That's not pg_dump's job though, so you're choosing a bad name for
it.  What I think you are really talking about is extending the
deparsing logic in ruleutils.c to cover utility statements.  Which is
not a bad plan in principle; we've just never needed it before.  It
would be quite a lot of new code though.

An issue that would have to be thought about is that there are assorted
scenarios where we generate "parse trees" that contain options that
cannot be generated from SQL, so there's no way to reverse-list them
into working SQL.  But often those hidden options are essential to know
what the statement will really do, so I'm not sure ignoring them will be
a workable answer for replication purposes.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: logical changeset generation v4
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: in-catalog Extension Scripts and Control parameters (templates?)