Robert Haas <robertmh...@gmail.com> writes:
> I am sure that we could find a way to beat this with a stick until it
> behaves, but I don't really like that idea. It seems to me to be a
[...]
> we should learn from that lesson: when you may want to have a bunch of
I first wanted to ensure that reusing existing parser keyword wouldn't
be well enough for our case as I find that solution more elegant. If we
can't think of future places where we would want to add support for
calling command triggers, then yes, you're right, something more
flexible is needed.
I'll go make that happen, and still need input here. We first want to
have command triggers on specific commands or ANY command, and we want
to implement 3 places from where to fire them.
Here's a new syntax proposal to cope with that:
create command trigger before COMMAND_STEP of alter table
execute procedure snitch();
- before the process utility switch, with only command tag and parse
tree
create command trigger foo before start of alter table
execute procedure snitch();
- before running the command, after having done basic error checks,
security checks, name lookups and locking, with all information
create command trigger before execute of alter table
execute procedure snitch();
- after having run the command
create command trigger foo before end of alter table
execute procedure snitch();
Some other places make sense to add support for, but working within the
delays we have and with the current patch, those 3 points are what's
easy enough to implement now.
>> I didn't think of DROP TABLE in a command table running BEFORE ALTER
>> TABLE, say. That looks evil. It could be documented as yet another way
>> to shoot yourself in the foot though?
>
> I think that for a first version of this feature it probably would be
> smart to trim this back to something that doesn't involve surgery on
> the guts of every command; then, we can extend incrementally.
A simple enough solution here would be to register a list disabled
commands per objectid before running the user defined function, and
check against that list before allowing it to run.
As we have command trigger support for all the commands we want to be
able to block, the lookup and ereport() call can be implemented in
InitCommandContext() where we already apply some limitations (like no
command triggers on command trigger commands).
Once that is in place it's possible to refine the pre-condition checks
on a per command basis and stop adding the command from the black list.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
