Re: [HACKERS] merging some features from plpgsql2 project

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: [HACKERS] merging some features from plpgsql2 project
Дата
Msg-id CAL9smLDCYLYs=0EDLRUc9NhvM6oSLxdBmf3HYHAvgSUPJvXDSQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] merging some features from plpgsql2 project  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] merging some features from plpgsql2 project  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On Tue, Jan 10, 2017 at 1:03 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
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).

This sounds useless.
 
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

And this a workaround for non-functional FOUND.

I can't get excited about this idea based on these examples.


.m

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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] merging some features from plpgsql2 project
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Increase pltcl test coverage