Re: Event Triggers: adding information
От | Andres Freund |
---|---|
Тема | Re: Event Triggers: adding information |
Дата | |
Msg-id | 20130122211459.GA27577@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Event Triggers: adding information (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2013-01-18 17:20:51 -0500, Robert Haas wrote: > On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> Well, that burden already exists for non-utility statements --- why > >>> should utility statements get a pass? Other than that we tend to invent > >>> new utility syntax freely, which might be a good thing to discourage > >>> anyhow. > > > >> My concerns are that (1) it will slow down the addition of new > >> features to PostgreSQL by adding yet another barrier to commit and (2) > >> it won't be get enough use or regression test coverage to be, or > >> remain, bug-free. > > > > Meh. The barriers to inventing new statements are already mighty tall. > > As for (2), I agree there's risk of bugs, but what alternative have you > > got that is likely to be less bug-prone? At least a reverse-list > > capability could be tested standalone without having to set up a logical > > replication configuration. > > > > This should not be interpreted as saying I'm gung-ho to do this, mind > > you. I'm just saying that if our intention is to support logical > > replication of all DDL operations, none of the alternatives look cheap. > > Well, we agree on that, anyway. :-) > > I honestly don't know what to do about this. I think you, Alvaro, and > I all have roughly the same opinion of this, which is that it doesn't > sound fun, but there's probably nothing better. Count me in. > So, what do we do > when a really cool potential feature (logical replication of DDL) > butts up against an expensive future maintenance requirement? I just tried to estimate the effort of that by looking at: git log REL9_1_0..REL9_2_0 src/backend/parser/gram.y src/include/nodes/ which seems like it would catch most such patches. First thing I have to say is there are more patches potentially affecting such a potential feature than I previously had thought. On the other hand, just about all of those patches are so big that the amount of changes to the ruleutils.c equivalent for DDL look like a minor pain in comparison to the rest. The patches that seemed relevant during 9.1=>9.2 seem to be to be the following when counting ones that directly would add new deparsing code: * NOT VALID * SECURITY LABEL * per column fdw options * range datatypes * security barrier * LEAKPROOF * privileges on types * ALTER FDW * rename domain constraints Then there were a bunch of patches adding new features that required restructuring of existing code that would have affected possible deparsing code: * plancache restructuring * parametrized indexscans * DROP ... consolidation In all of those but "ALTER FDW" and "rename domain constraints" possible deparsing code looks like it would be an absolutely minor part of the code. And in those its only a relevant part because they are really small. There were some bugfixes that would have required touching it as well, but those seemed to be cases that are basically s/a/b/. Not sure what the consequence of that is, but I wanted to share it anyway after spending the time ;). > I'm not > even sure what the criteria should be for making a decision on whether > it's "worth it". In my experience it is the weakest point in the non-WAL based postgres replication tools. So I personally think it is worth some overhead when adding new features. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Jameison MartinДата:
Сообщение: Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Следующее
От: Tom LaneДата:
Сообщение: Re: psql: small patch to correct filename formatting error in '\s FILE' output