Re: [HACKERS] merging some features from plpgsql2 project - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] merging some features from plpgsql2 project
Date
Msg-id CAFj8pRAopNbWJ19=tB=0_2HoyTf7XEJsueeL+Lt_pTGkN+GrDQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] merging some features from plpgsql2 project  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: [HACKERS] pg_restore accepts -j -1
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] merging some features from plpgsql2 project