pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedDynamic queries in stored procedure
4+ messages / 4 participants
[nested] [flat]
* Dynamic queries in stored procedure
@ 2013-07-05 13:57 Greg Jaskiewicz <gryzman@gmail.com>
2013-07-05 14:26 ` Re: Dynamic queries in stored procedure Andrew Dunstan <andrew@dunslane.net>
2013-07-05 14:46 ` Re: Dynamic queries in stored procedure Misa Simic <misa.simic@gmail.com>
0 siblings, 2 replies; 4+ messages in thread
From: Greg Jaskiewicz @ 2013-07-05 13:57 UTC (permalink / raw)
To: pgsql-performance
Hey,
We have a search method that depending on search params will join 3-5 tables, craft the joins and where section. Only problem is, this is done in rather horrible java code. So using pgtap for tests is not feasible.
I want to move the database complexity back to database, almost writing the query construction in the plpgsql or python as stores procedure, any suggestions ?
Unfortunately PostgreSQL won't eliminate unnecessary joins from a view, so I can't just create one view and simple code adding where's, order by, etc.
No, I don't want to use orm.
Thanks.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Dynamic queries in stored procedure
2013-07-05 13:57 Dynamic queries in stored procedure Greg Jaskiewicz <gryzman@gmail.com>
@ 2013-07-05 14:26 ` Andrew Dunstan <andrew@dunslane.net>
2013-07-05 14:50 ` Re: Dynamic queries in stored procedure Scott Barney <scott@calculatedsteam.com>
1 sibling, 1 reply; 4+ messages in thread
From: Andrew Dunstan @ 2013-07-05 14:26 UTC (permalink / raw)
To: Greg Jaskiewicz <gryzman@gmail.com>; +Cc: pgsql-performance
On 07/05/2013 09:57 AM, Greg Jaskiewicz wrote:
> Hey,
>
> We have a search method that depending on search params will join 3-5 tables, craft the joins and where section. Only problem is, this is done in rather horrible java code. So using pgtap for tests is not feasible.
> I want to move the database complexity back to database, almost writing the query construction in the plpgsql or python as stores procedure, any suggestions ?
>
> Unfortunately PostgreSQL won't eliminate unnecessary joins from a view, so I can't just create one view and simple code adding where's, order by, etc.
>
> No, I don't want to use orm.
>
It's a matter of taste. Pretty much every PL has facilities for
constructing and running dynamic sql. PLPgsql ,PLPerl, PLV8 ...
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Dynamic queries in stored procedure
2013-07-05 13:57 Dynamic queries in stored procedure Greg Jaskiewicz <gryzman@gmail.com>
2013-07-05 14:26 ` Re: Dynamic queries in stored procedure Andrew Dunstan <andrew@dunslane.net>
@ 2013-07-05 14:50 ` Scott Barney <scott@calculatedsteam.com>
0 siblings, 0 replies; 4+ messages in thread
From: Scott Barney @ 2013-07-05 14:50 UTC (permalink / raw)
To: pgsql-performance
I do this all the time; In fact, I've written a dynamic aggregate engine
that uses a sudo bind variable technique & dynamic joins with dependency
injection because the table names and query logic are not known at run
time - all in plpgsql.
sb
On 7/5/2013 9:26 AM, Andrew Dunstan wrote:
>
> On 07/05/2013 09:57 AM, Greg Jaskiewicz wrote:
>> Hey,
>>
>> We have a search method that depending on search params will join 3-5
>> tables, craft the joins and where section. Only problem is, this is
>> done in rather horrible java code. So using pgtap for tests is not
>> feasible.
>> I want to move the database complexity back to database, almost
>> writing the query construction in the plpgsql or python as stores
>> procedure, any suggestions ?
>>
>> Unfortunately PostgreSQL won't eliminate unnecessary joins from a
>> view, so I can't just create one view and simple code adding where's,
>> order by, etc.
>>
>> No, I don't want to use orm.
>>
>
> It's a matter of taste. Pretty much every PL has facilities for
> constructing and running dynamic sql. PLPgsql ,PLPerl, PLV8 ...
>
> cheers
>
> andrew
>
>
>
>
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Dynamic queries in stored procedure
2013-07-05 13:57 Dynamic queries in stored procedure Greg Jaskiewicz <gryzman@gmail.com>
@ 2013-07-05 14:46 ` Misa Simic <misa.simic@gmail.com>
1 sibling, 0 replies; 4+ messages in thread
From: Misa Simic @ 2013-07-05 14:46 UTC (permalink / raw)
To: Greg Jaskiewicz <gryzman@gmail.com>; +Cc: pgsql-performance
2013/7/5 Greg Jaskiewicz <gryzman@gmail.com>
> Hey,
>
> We have a search method that depending on search params will join 3-5
> tables, craft the joins and where section. Only problem is, this is done in
> rather horrible java code. So using pgtap for tests is not feasible.
> I want to move the database complexity back to database, almost writing
> the query construction in the plpgsql or python as stores procedure, any
> suggestions ?
>
> Unfortunately PostgreSQL won't eliminate unnecessary joins from a view, so
> I can't just create one view and simple code adding where's, order by, etc.
>
> No, I don't want to use orm.
>
> Thanks.
>
>
If returning type of function is always the same - you can achieve that
with any pl language in postgres...
before 9.2 we have used plv8 (to return text as formated JSON) - because of
we haven't known expected number of columns and type for each column in
moment we created function....
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2013-07-05 14:50 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-07-05 13:57 Dynamic queries in stored procedure Greg Jaskiewicz <gryzman@gmail.com>
2013-07-05 14:26 ` Andrew Dunstan <andrew@dunslane.net>
2013-07-05 14:50 ` Scott Barney <scott@calculatedsteam.com>
2013-07-05 14:46 ` Misa Simic <misa.simic@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox