Re: PL/pgSQL 2

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: PL/pgSQL 2
Дата
Msg-id 20140901092442.GA5786@awork2.anarazel.de
обсуждение исходный текст
Ответ на PL/pgSQL 2  (Joel Jacobson <joel@trustly.com>)
Ответы Re: PL/pgSQL 2  (Hannu Krosing <hannu@2ndQuadrant.com>)
Re: PL/pgSQL 2  (Joel Jacobson <joel@trustly.com>)
Re: PL/pgSQL 2  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 2014-09-01 11:04:53 +0200, Joel Jacobson wrote:
> For those of you who use PL/pgSQL every day, I'm quite certain you all feel
> there are a number of things you would like to change in the language, but
> realize it cannot be achieved without possibly breaking compatibility, at
> least in theory. Even though you own code would survive the change, there
> might be code somewhere in the world which would break. This is of course
> not acceptable and that's why we have the current status quo of
> development, or at least not far away from a status quo.
> 
> So instead of continue to adding optional settings to the config file, and
> instead of killing discussions around what can be done by bringing up the
> backwards-compatibility argument, let's instead fork the language and call
> it plpgsql2. Since no code is yet written in plpgsql2, we can start of from
> a clean sheet, and no good ideas need to be killed due to
> backwards-compatibility concerns.
> 
> The interest for such a project is probably limited to a small number of
> companies/people around the world, as most users are probably perfectly
> happy with the current version of plpgsql, as they only use it occasionally
> and not every day like we do at my company.
> 
> Just like with plpgsql, once released, plpgsql2 cannot break compatibility
> with future versions, so we only have one chance to carefully think though
> what we would like to change in the language.
> 
> From the top of my head, these are Things I personally would want to see in
> plpgsql2:
> + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1
> row, as that's the most common use-case, and provide alternative syntax to
> modify multiple or zero rows.
> + Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO
> STRICT only works if no rows should be an error, but there is currently no
> nice way if no rows OR exactly 1 row should be found by the query.
> + Change all warnings into errors

-many.

Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.

You're going to have to find a more gradual way of doing this.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Joel Jacobson
Дата:
Сообщение: Re: PL/PgSQL: EXIT USING ROLLBACK
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Better support of exported snapshots with pg_dump