From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Pass where clause to a function |
Date: | 2014-08-14 13:47:29 |
Message-ID: | CAHyXU0y06JEPL48G66kt7z_k=t3mkgVBw=b7C61fyd_0jdDdkQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Aug 14, 2014 at 1:17 AM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 8/13/2014 10:59 PM, Andrew Bartley wrote:
>
> I need this because it is a customer requirement. The underlying tables the
> api will query are dynamically created, they are period/content partitioned
> and distributed across multiple servers and database types... not just
> postgres. The api/function will determine what servers/databases/tables
> (some of them are foreign tables) to query based on the parameters passed to
> the api. The customer wants to use their current reporting tool that does
> not support function selects.
>
>
> I don't know how you would pass those expression fragments to a view to be
> passed to the function, however.
>
> what you describe above (and in the rest of your post) sounds very
> convoluted, and rather prone to poor performance.
Also be advised that sending user generated raw text to an EXECUTE'd
statement is a horrible injection risk. It's still ok (somtimes) but
only in a 100% trust situation. Perhaps you could add a little bit of
safety by adding making two arguments: comparison field and comparison
value and using quote_ident/quote_literal around them; it's a good
habit to use quote_xx around any token that is possible to be supplied
by a human.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2014-08-14 14:16:11 | Re: Trigger function cannot reference field name with capital letter |
Previous Message | Adrian Klaver | 2014-08-14 13:41:00 | Re: Trigger function cannot reference field name with capital letter |