On 02/28/2015 01:39 PM, Jan de Visser wrote:
> On February 28, 2015 03:39:06 PM inspector morse wrote:
>> Is it a good idea to write a simple application (consisting of just data
>> entry interfaces) in pure pgsql?
>>
>> Basically, we would have each page has a stored function in postgresql that
>> is called by php+apache (the http get/post values would be passed into
>> postgrel as an array).
>>
>> The pgpsql would render HTML and return back to the front end for display.
>>
>> Sample:
>> create function render_user_login_page(out v_html varchar)
>> returns varchar
>> as
>> $$
>> begin
>> v_html := v_html || '<table><tr><td>User ID:</td><td><input
>> type="text" /></td></tr></table>';
>> end;
>> $$
>>
>>
>> Would there be any performance issues with doing this?
>
> Don't know about the performance aspects, but just thinking about it you're
> making your db server responsible for a lot of cruft that can easily be
> outsourced - the HTML rendering. Which, besides being a potential performance
> pitfall, will probably end up being a terrible maintenance nightmare.
The thought of doing CREATE OR REPLACE FUNCTION every time a Web page
needed to be modified gives me the jitters.
>
> What's the problem with letting PHP do what it's good at, i.e. rendering
> templatized HTML, and let the DB do what it's good at - data processing? The
> idea of sending stuff over straight to the DB sounds sane, but instead of doing
> that terrible string concat stuff you're thinking of just send back some
> structured data which you then render in PHP?
Yea, I am pretty sure that was the problem REST was created to solve.
>
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
