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
