Re: Event Triggers: adding information

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Event Triggers: adding information
Дата
Msg-id 16675.1358454278@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Event Triggers: adding information  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Event Triggers: adding information  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Event Triggers: adding information  (Simon Riggs <simon@2ndquadrant.com>)
Re: Event Triggers: adding information  (Craig Ringer <craig@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 17 January 2013 16:15, Robert Haas <robertmhaas@gmail.com> wrote:
>> It pains me that I've evidently failed to communicate this concept
>> clearly despite a year or more of trying.  Does that make sense?  Is
>> there some way I can make this more clear?  The difference seems very
>> clear-cut to me, but evidently I'm not conveying it well.

> "The point", i.e. the main use case, is to replicate the DDL in a useful form.

> Discussions and reasoning need to focus on the main use case, not on
> weird futures or qualitative points.

I have to completely disagree with that.  If we don't want PostgreSQL
to soon subside into an unfixable morass, as I think Brooks puts it,
we must *not* simply patch things in a way that expediently provides
an approximation of some desired feature.  We have to consider, and put
substantial weight on, having a clean and maintainable system design.

This is particularly the case if we're talking about a feature that
is going to expose backend internals to users to any degree.  We're
either going to be constrained to not change those internals any more,
or expect to break users' applications when we do change them, and
neither result is very appealing.  Especially not when we're talking
about the structure of Postgres' DDL code, which can most charitably
be described as "it just grew", not as something that has any clear
architecture to it.

Now if we could quantify these things, that would be great, but
AFAICS "qualitative points" is all we've got to go on.

I think that we're not realistically going to be able to introduce
event triggers in very many of the places we'd like to have them
without first doing a lot of fundamental refactoring.  And that is
hard, dangerous, slow work that tends to break things in itself.
As we've been repeatedly reminded in connection with KaiGai-san's
refactoring patches.

So my opinion is that most of what we'd like to have here is material
for 9.4 or 9.5 or even further out.  If we can get the event trigger
catalog infrastructure and some *very* basic events, like
end-of-toplevel-command, into place for 9.3, we'll have done well.
        regards, tom lane



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

Предыдущее
От: Stefan Keller
Дата:
Сообщение: Re: 9.3 Pre-proposal: Range Merge Join
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Event Triggers: adding information