Re: [HACKERS] merging some features from plpgsql2 project

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] merging some features from plpgsql2 project
Дата
Msg-id CAFj8pRAopNbWJ19=tB=0_2HoyTf7XEJsueeL+Lt_pTGkN+GrDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] merging some features from plpgsql2 project  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Дерево обсуждения


2017-01-10 2:02 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/9/17 6:07 PM, Marko Tiikkaja wrote:
    One use case is NEW and OLD in triggers. Checking to see if one or
    the other is set is easier than checking TG_OP. It's also going to
    be faster (probably MUCH faster; IIRC the comparison currently
    happens via SPI).


This sounds useless.

 I guess you've not written much non-trivial trigger code then... the amount of code duplication you end up with is quite ridiculous. It's also a good example of why treating this as an exception and trapping isn't a good solution either: you can already do that with triggers today.

Being able to check the existence of a variable is a very common idiom in other languages, so I'm don't see why plpgsql shouldn't have it.

In strongly typed language like PLpgSQL is DEFINE little bit strange. On second hand there are some elements of dynamic languages - record types and polymorphics parameters.

Some languages has reflection API - some other like Oberon some special statements - variable guards that allows safe casting and safe usage - it is not far what we do with Node API.



 

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: [HACKERS] pg_restore accepts -j -1
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] merging some features from plpgsql2 project