From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: merging some features from plpgsql2 project |
Date: | 2017-01-10 00:03:18 |
Message-ID: | cb8e5549-00ef-2c7a-8df3-0f159880daca@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/9/17 5:53 PM, Marko Tiikkaja wrote:
> My idea was that the currently unsupported combination of NOT
> NULL and
> no DEFAULT would mean "has to be assigned to a non-NULL value
> before it
> can be read from, or an exception is thrown". Solves the most
> common
> use case and is backwards compatible.
>
>
> That won't allow you to use a variable in multiple places though...
> is there a reason we couldn't support something like IS DEFINED and
> UNSET?
>
>
> I don't understand what your use case is. Could you demonstrate that
> with some code you'd write if these features were in?
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).
Another case is selecting into a record:
EXECUTE ... INTO rec;
IF rec IS DEFINED THEN
ELSE
EXECUTE <something else> INTO rec;
IF rec IS DEFINED THEN
...
Perhaps DEFINED is not the best keyword. Ultimately I want to know if a
variable has been assigned a value, as well as being able to mark a
variable as unassigned (though arguably you might not need to be able to
un-assign...).
--
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2017-01-10 00:07:26 | Re: merging some features from plpgsql2 project |
Previous Message | Jim Nasby | 2017-01-09 23:56:48 | Re: merging some features from plpgsql2 project |