Re: PL/pgSQL 1.2

From: Oskari Saarenmaa <os(at)ohmu(dot)fi>
To: Jan Wieck <jan(at)wi3ck(dot)info>, Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 1.2
Date: 2014-09-06 17:34:00
Message-ID: 540B4588.1060505@ohmu.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

06.09.2014 19:12, Jan Wieck kirjoitti:
> On 09/06/2014 04:21 AM, Marko Tiikkaja wrote:
>> We wrap these things into (sometimes) simple-looking function so that
>> none of the application developers ever run any SQL. We define an
>> interface between the application and the database, and that interface
>> is implemented using PL/PgSQL functions. Sure, sometimes one function
>> will just fire off a single UPDATE .. RETURNING, or a SELECT, but that
>> doesn't matter. The trick is to be consistent everywhere.
>
> There is precisely your root problem. Instead of educating your
> application developers on how to properly use a relational database
> system, you try to make it foolproof.

There are also other reasons to wrap everything in functions, for
example sharding using pl/proxy which by the way always throws an error
if a SELECT didn't match exactly one row and the function wasn't
declared returning 'SETOF' (although it currently doesn't set any
sqlstate for these errors making it a bit difficult to properly catch them.)

Anyway, I think the discussed feature to make select, update and delete
throw an error if they returned or modified <> 1 row would be more
useful as an extension of the basic sql statements instead of a plpgsql
(2) only feature to make it possible to use it from other languages and
outside functions.

/ Oskari

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-09-06 17:41:11 Re: PL/pgSQL 1.2
Previous Message Marko Tiikkaja 2014-09-06 17:26:26 Re: proposal: plpgsql - Assert statement