From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Michael Moore <michaeljmoore(at)gmail(dot)com> |
Cc: | postgres list <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: is this a good approach? |
Date: | 2016-05-14 01:50:56 |
Message-ID: | CAKFQuwZt2bqAX9u2XqxKBEzatbNV74yfVgO9k6uQhQ6a=x57Jg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, May 13, 2016 at 5:52 PM, Michael Moore <michaeljmoore(at)gmail(dot)com>
wrote:
> 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 example
>
> sql_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 like
>
>> case 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
> <https://oracle-base.com/articles/9i/dynamic-binds-using-contexts>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Moore | 2016-05-14 15:46:59 | Re: is this a good approach? |
Previous Message | Ezequiel Luis Pellettieri | 2016-05-14 00:26:46 | Re: Create a trigger only for certain users |