Re: Add CREATE support to event triggers
От | Alvaro Herrera |
---|---|
Тема | Re: Add CREATE support to event triggers |
Дата | |
Msg-id | 20140106181732.GB6840@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Add CREATE support to event triggers (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Add CREATE support to event triggers
Re: Add CREATE support to event triggers |
Список | pgsql-hackers |
Robert Haas escribió: > I think this direction has some potential. I'm not sure it's right in > detail. The exact scheme you propose above won't work if you want to > leave out the schema name altogether, and more generally it's not > going to help very much with anything other than substituting in > identifiers. What if you want to add a column called satellite_id to > every table that gets created, for example? What if you want to make > the tables UNLOGGED? I don't see how that kind of things is going to > work at all cleanly. Thanks for the discussion. I am building some basic infrastructure to make this possible, and will explore ideas to cover these oversights (not posting anything concrete yet because I expect several iterations to crash and burn before I have something sensible to post). > What I can imagine that might work is that you get a JSON blob for a > create table statement and then you have a function > make_a_create_table_statement(json) that will turn it back into SQL. > You can pass a modified blob (adding, removing, or changing the > schema_name or any other element) instead and it will do its thing. I agree, except that I would prefer not to have one function for each DDL statement type; instead we would have a single function that knows to expand arbitrary strings using arbitrary JSON parameter objects, and let ddl_rewrite.c (or whatever we call that file) deal with all the ugliness. One function per statement would increase the maintenance cost more, I think (three extra pg_proc entries every time you add a new object type? Ugh.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: