Hello,
Thank you for your answer Robert.
> Well, SQL, our our dialect of it anyway, doesn't have global
> variables. So I think the above is going to throw a syntax error.
> You may have global variables in your C code, but those won't be
> visible from the SQL level.
I was wrong in the definition of filtered_employees view.
The correct one is :
CREATE OR REPLACE VIEW filtered_employees AS
SELECT *, get_mu() as mu
FROM employees
ORDER BY mu DESC
LIMIT get_k();
Note that the access to global C variables (K, MU and ALPHA) from SQL is working well with my definitions of get_k(), get_mu()... There is no syntax error here, however the view is not working because it has side effects on the value of MU.
I have also tried two other alternatives to the LIMIT keyword but it doesn't work yet :
1) SQL instruction : RANK() OVER(ORDER BY get_mu()) as sqlf_rank ;
2) C instruction : SPI_exec(query, K) ... it leads to a segmentation fault.
> In general, I think you'd be better off not relying on C global
> variables either,
I don't understand how I could avoid using global variables in some cases.
For instance, I must store the float value $1 corresponding to a fuzzy predicate degree in the following fuzzy2bool cast operation :
CREATE OR REPLACE FUNCTION fuzzy2bool(FLOAT)
RETURNS BOOLEAN LANGUAGE SQL AS
'SELECT set_mu($1); -- Here $1 must be stored in MU for each record observed in the view;
SELECT $1 > get_alpha()'; -- Then $1 is converted to Boolean according to ALPHA global value
> and instead passing the values you need as function
> arguments.
Do you mean that I should define a function filter(table_name TEXT, k INTEGER, alpha FLOAT) ?
Thanks again for your help,
Thomas Girault