Re: PL/PgSQL STRICT

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <pgmail(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/PgSQL STRICT
Date: 2012-12-21 16:09:28
Message-ID: CAFNqd5VZ3RXUQe=E7s6azfkisDFUDtfRGJXDfq+0FTOL4dtDmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 21, 2012 at 10:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Marko Tiikkaja <pgmail(at)joh(dot)to> writes:
> > Courtesy of me, Christmas comes a bit early this year. I wrote a patch
> > which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
> > without specifying an INTO clause.
>
> What is the use-case for this? Won't this result in the word STRICT
> becoming effectively reserved in contexts where it currently is not?
> (IOW, even if the feature is useful, I've got considerable doubts about
> this syntax for it. The INTO clause is an ugly, badly designed kluge
> already --- let's not make another one just like it.)

Yep, the use case for this seems mighty narrow to me.

I could use GET DIAGNOSTICS to determine if nothing got altered, and
it seems likely to me that expressly doing this via IF/ELSE/END IF would
be easier to read in function code than a somewhat magic STRICT
side-effect.

I certainly appreciate that brevity can make things more readable, it's
just
that I'm not sure that is much of a help here.

This is adding specific syntax for what seems like an unusual case to me,
which seems like an unworthwhile complication.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Johnston 2012-12-21 16:13:20 Re: PL/PgSQL STRICT
Previous Message Marko Kreen 2012-12-21 16:05:10 pgcrypto seeding problem when ssl=on