Re: Dyamic updates of NEW with pl/pgsql

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Dyamic updates of NEW with pl/pgsql
Дата
Msg-id b42b73151003150639h26be3fc8m60812c7b9d6d8db7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dyamic updates of NEW with pl/pgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Dyamic updates of NEW with pl/pgsql  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Sat, Mar 13, 2010 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wonder if it could work to treat the result of a "record->fieldname"
> operator as being of UNKNOWN type initially, and resolve its actual
> type in the parser in the same way we do for undecorated literals
> and parameters, to wit
>        * you can explicitly cast it, viz
>                (record->fieldname)::bigint
>        * you can let it be inferred from context, such as the type
>          of whatever it's compared to
>        * throw error if type is not inferrable
> Then at runtime, if the actual type of the field turns out to not be
> what the parser inferred, either throw error or attempt a run-time
> type coercion.  Throwing error seems safer, because it would avoid
> surprises of both semantic (unexpected behavior) and performance
> (expensive conversion you weren't expecting to happen) varieties.
> But possibly an automatic coercion would be useful enough to justify
> those risks.

the casting rules are completely reasonable.  Throwing an error seems
like a better choice.  Better to be strict now and relax the rules
later.  record->fieldname takes a string (possibly a variable)?  If
so, his would nail the problem.  This would work with run time typed
records (new, etc)?

merlin


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Getting to beta1
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Dyamic updates of NEW with pl/pgsql