On 19 November 2013 16:46, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Nov 19, 2013 at 12:45 AM, Noah Misch <noah@leadboat.com> wrote:
>> On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
>>> The triggers don't fire if there is no real XID, so only actual data
>>> changes should cause the trigger to fire.
>>
>> What's the advantage of this provision? Without it, an individual trigger
>> could make the same check and drop out quickly. A trigger not wanting it
>> can't so easily work around its presence, though. Heretofore, skipping XID
>> assignment has been an implementation detail that improves performance without
>> otherwise calling user attention to itself. This provision would make the
>> decision to acquire an XID (where optional) affect application behavior.
>
> Yeah, I agree that that's an ugly wart. If we want a pre-commit
> trigger that's only called for transactions that write data, we at
> least need to name it appropriately.
It looks to me that this idea is horribly physical and seems likely to
be badly misused.
I don't see any way to use these that won't be quite ugly. There is no
trigger descriptor, so no way of writing a constraint sensibly, since
you'll need to make a constraint check for every commit by every user,
not just ones that touch the data you care about. And security goes
straight out the window, so these can't be used in normal application
development.
Plus we can already do this with RegisterXactCallback() as Alvaro
points out - so if its a hack we're after, then we already have it, no
patch required.
So this patch doesn't give us anything genuinely useful for
application developers, nor does it give us the thing that Josh is
looking for..
>The main reason is to enforce arbitrary assertions which need
> enforcement at the end of a transaction and not before.
I like the goal, but this is not the solution.
Josh also points out...
>This is the sort of thing the SQL committee covered in ASSERTIONS, but
> of course they never specified any method for implementation.
I think we should be thinking harder about how to implement
ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit
write event triggers.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
