Re: merging some features from plpgsql2 project

2017-01-10 2:02 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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)
>