Re: is this a good approach? - Mailing list pgsql-sql
From | David G. Johnston |
---|---|
Subject | Re: is this a good approach? |
Date | |
Msg-id | CAKFQuwZt2bqAX9u2XqxKBEzatbNV74yfVgO9k6uQhQ6a=x57Jg@mail.gmail.com Whole thread Raw |
In response to | is this a good approach? (Michael Moore <michaeljmoore@gmail.com>) |
Responses |
Re: is this a good approach?
|
List | pgsql-sql |
I have a function that accepts about 20 input parameters. Based on the values of these parameters a SELECT statement will be constructed. The SELECT will be from two main tables, but based on parameters it might join up to 3 additional tables. the WHERE clause will have many possibilities too. The where clause will reference various input parameters. In other words, it's a hot mess and only god knows what the SELECT statement will look like by the time all the pieces are lashed together. The only thing that won't vary is the column list. That is fixed.All of the above is pretty much not up for redesign as I am duplicating some functionality that exists in Oracle. One of the goals of my design is to minimize the number of distinct cursors that are the result of cursor parses. To that end I will be using the USING clause. For examplesql_select :=
'SELECT vendor_key::text rslt from tx_vendor where vendor_key = any ($1)';
return query execute sql_select using v_blurb_type_codes;The problem is, I will have a variable number of USING arguments with differing datatypes depending on how the SELECT statement gets built.So, my brilliant idea is to load the needed values into a JSONB where the key to each of the jsonb values is a sequential number. It would look something like:{"1":"good","2":"1234,4321,7787","3":"overtime"}Then, when I go to execute the query it will look likecase countOfParmsUsedInSQL
when 1 then
return query execute sql_select using json_vars::jsonb->>'1';
when 2 then
return query execute sql_select using json_vars::jsonb->>'1',json_vars::jsonb->>'2';
when 3 then
return query execute sql_select using json_vars::jsonb->>'1',json_vars::jsonb->>'2',json_vars::jsonb->>'3';
end;So, my questions are:
1) Will this work? I am concerned that I will have trouble with the datatypes in jsonb. i.e. for example, sometimes parameter 2 might be a NUMBER and other times it might be ::bigint[] (bigint[] would be used in cases like $1 shown in my first example above.
I know you said ignore this but it should be at least technically possible (though never tried it myself) - though maybe hstore would be a better serialization mechanism. You'd have to ensure that values are all valid text/literal inputs for the specified parameters which themselves would have casts on them. So key 2 would have to be <'{1234,4321,7787}'> which is then cast as <::bigint[]?
2) Is there a better way to avoid string concatenation of parameters which will result in thousands of hard parses? Oracle has dynamic binding variables to help solve this problem.I only mention this in case I have not explained adequately the nature of the problem I am trying to solve.
Custom GUC session globals?
set_config('prefix.name', 'value')
current_setting('prefix.name') --> value
This becomes nicer in 9.6 with the ability to supply a default for a missing variable on the current_setting call.
A quick look at "context" in the Oracle link this is what looks to be our closest equivalent.
In more recent versions you will get an error if the variable prefix.name does not exist so you either need to dynamically ensure it is not requested when not needed or structure code so that default values to setup and then overridden by user-defined values.
David J.