Re: PL/pgSQL 1.2 - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: PL/pgSQL 1.2
Date
Msg-id CAASwCXdnm68YMbS7SXi1QXGEgXH0Nbo-bZm5k9xRka2FSVP2wA@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 1.2  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: PL/pgSQL 1.2
List pgsql-hackers
On Wed, Sep 3, 2014 at 11:19 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> SELECT[1]   - select exactly one row, anything else raises error
> SELECT[0:1]   - select zero or one rows, anything else raises error
> SELECT[1:] - select one or more rows
>
> plain SELECT is equivalent to SELECT[0:]
>
> same syntax could be used for enforcing sane affected row counts
> for INSERT and DELETE

+1 for a new fresh creative idea! My mind was stuck in a "looking for
keywords" state.

The only suggestion I think is slightly better is the "STRICT UPDATE",
but only if I'm right assuming the "one row" use-case is much more
common than the "zero or one rows" and "one or more rows" use-cases.

If all use-cases are equally important to support in a nice way,
then the suggested syntax is brilliant, as it supports all of them.

Bonus points for the extremely condensed syntax.

> 2. Substitute for EXECUTE with string manipulation
> ----------------------------------------------------------------
>
> using backticks `` for value/command substitution in SQL as an alternative
> to EXECUTE string

+1 for being backwards compatible, but I have no strong opinion.

> 3. A way to tell pl/pggsql not to cache plans fro normal queries
> -----------------------------------------------------------------------------------

> OR we could do it in SQL-ish way using like this:
>
> SELECT
> ...
> USING FRESH PLAN;

+1 for clean syntax



pgsql-hackers by date:

Previous
From: Alexey Klyukin
Date:
Subject: Re: implement subject alternative names support for SSL connections
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL 1.2