Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trigger_is(): allow testing function arguments #83

Open
decibel opened this issue May 8, 2015 · 7 comments
Open

trigger_is(): allow testing function arguments #83

decibel opened this issue May 8, 2015 · 7 comments

Comments

@decibel
Copy link
Collaborator

decibel commented May 8, 2015

It'd be good if we could verify the arguments (or at least number of arguments) being passed to a trigger function by a specific trigger. According to [1], The arguments are concatinated together as NUL terminated strings in pg_trigger.tgargs.

1: http://www.postgresql.org/docs/devel/static/catalog-pg-trigger.html

@rodo
Copy link
Contributor

rodo commented Jun 28, 2016

Actually trigger_is is defined as is :

SELECT trigger_is( :schema, :table, :trigger, :func_schema, :function, :description );
SELECT trigger_is( :schema, :table, :trigger, :func_schema, :function );
SELECT trigger_is( :table, :trigger, :function, :description );
SELECT trigger_is( :table, :trigger, :function );

What about adding these functions to detect the number of argument ?

SELECT trigger_is( :schema, :table, :trigger, :func_schema, :function, nbargs, :description );
SELECT trigger_is( :schema, :table, :trigger, :func_schema, :function, nbargs );
SELECT trigger_is( :table, :trigger, :function, :description, nbargs );
SELECT trigger_is( :table, :trigger, :function, nbargs );

@decibel
Copy link
Collaborator Author

decibel commented Jun 29, 2016

That would be better than nothing.

Another option would be to use the trigger definition parsing code I wrote for cat_tools.

@rodo
Copy link
Contributor

rodo commented Jun 29, 2016

I'll have a look at your function, as your code is under MIT License too it's possible to use it in pgtap, it's better to keep pgtap with less dependencies as possible.

@theory
Copy link
Owner

theory commented Jun 29, 2016

Jesus, trigger parsing code? In PL/pgSQL? o_O

@decibel
Copy link
Collaborator Author

decibel commented Jun 29, 2016

Well, I wanted it to be portable... It's not quite as bad as you might
think.

If we didn't care about portable then I think the best way to handle
this would be a C function that calls (or duplicates) the appropriate
bits of backend code. I don't think that some other PL language buys us
much over the plpgsql, and the C code means nothing's actually being parsed.

@theory
Copy link
Owner

theory commented Jun 30, 2016

I'm sure it's no worse than some of the crazy shit PL/pgSQL already does, like trying to distinguish a string that executes a prepared statement from any other query. Fine with me to integrate that code if you're willing to contribute it, @decibel.

@decibel
Copy link
Collaborator Author

decibel commented Jun 30, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants