Re: PL/PgSQL STRICT

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: PL/PgSQL STRICT
Дата
Msg-id CAFNqd5VZ3RXUQe=E7s6azfkisDFUDtfRGJXDfq+0FTOL4dtDmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/PgSQL STRICT  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PL/PgSQL STRICT
Re: PL/PgSQL STRICT
Список pgsql-hackers
On Fri, Dec 21, 2012 at 10:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Marko Tiikkaja <pgmail@joh.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?"

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: pgcrypto seeding problem when ssl=on
Следующее
От: "David Johnston"
Дата:
Сообщение: Re: PL/PgSQL STRICT