Message-ID: <51D6D7A2.3030206@dunslane.net>
Date: Fri, 05 Jul 2013 10:26:42 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Greg Jaskiewicz <gryzman@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Dynamic queries in stored procedure
References: <96F5E9DF-8F6E-4EF6-B0AE-43B585B11F94@gmail.com>
In-Reply-To: <96F5E9DF-8F6E-4EF6-B0AE-43B585B11F94@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


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