Re: different results from plpgsql functions related to last changesin master - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: different results from plpgsql functions related to last changesin master
Date
Msg-id CAFj8pRAHu+1U1wzHwQgJCzb8XvH4fEwNEWEPRXrEBcTdS0i_Rw@mail.gmail.com
Whole thread Raw
In response to Re: different results from plpgsql functions related to last changes in master  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2018-02-18 17:48 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I did update of plpgsql_check and I see, so some functions returns
> different result than on older posgresql. Probably this is wanted behave,
> but It should be mentioned as partial compatibility break, because some
> regress test can be broken too.

This is mentioned in the relevant commit message (4b93f5799):

    ...  A lesser, but still real, annoyance is that ROW format cannot
    represent a true NULL composite value, only a row of per-field NULL
    values, which is not exactly the same thing.

In the case you're showing here, a true NULL got changed into ROW(NULL)
by the old code, but that no longer happens.

I understand, and I have not any problem with this behave. Just I am expecting so lot of people will be surprised.

Regards

Pavel
 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: different results from plpgsql functions related to last changes in master
Next
From: Dmitry Dolgov
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().