Re: [HACKERS] revision of todo: NULL for ROW variables
On Oct 28, 2010, at 11:41 AM, Merlin Moncure wrote: On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: I am checking PLpgSQL ToDo topics, and I am not sure if this topic isn't done. And if not, then I would to get some detail. I think that thread petered out because we didn't have consensus on what the behavior ought to be. It goes back to whether there is supposed to be a difference between NULL and ROW(NULL,NULL,NULL,...) I think somewhere along the line it was noticed that SQL says you are supposed to treat (null, null) as null and the behavior of 'is null' operator was changed to reflect this while other null influenced behaviors were left intact (for example, coalesce()). My take on this is that we are stuck with the status quo. If a change must be done, the 'is null' change should be reverted to un-standard behavior. The SQL standard position on this issue is, IMNSHO, on mars. As someone who's wanted this... what if we had a dedicated function to tell you if a row variable had been defined? I definitely don't like the though of creating something that effectively duplicates IS NULL, but I'd much rather that than continue not having the ability to tell if a row/record variable has been set or not. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] revision of todo: NULL for ROW variables
On Mon, 2010-11-01 at 09:44 -0500, Jim Nasby wrote: My take on this is that we are stuck with the status quo. If a change must be done, the 'is null' change should be reverted to un-standard behavior. The SQL standard position on this issue is, IMNSHO, on mars. As someone who's wanted this... what if we had a dedicated function to tell you if a row variable had been defined? I definitely don't like the though of creating something that effectively duplicates IS NULL, but I'd much rather that than continue not having the ability to tell if a row/record variable has been set or not. If we just invent a couple more variants of NULL, it will solve all our problems ;) Seriously though, I think that we should stick as closely to the letter of the standard as possible here (or, if there is ambiguity, pick one reasonable interpretation). NULL semantics are confusing enough without everyone making their own subtle tweaks. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] revision of todo: NULL for ROW variables
Jeff Davis pg...@j-davis.com wrote: Seriously though, I think that we should stick as closely to the letter of the standard as possible here (or, if there is ambiguity, pick one reasonable interpretation). NULL semantics are confusing enough without everyone making their own subtle tweaks. +1 If the standard behavior doesn't support all the functionality we need, we should be looking at PostgreSQL extensions which do not conflict with standard syntax. Supporting standard syntax with different semantics is evil. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] revision of todo: NULL for ROW variables
On Mon, Nov 1, 2010 at 2:29 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Jeff Davis pg...@j-davis.com wrote: Seriously though, I think that we should stick as closely to the letter of the standard as possible here (or, if there is ambiguity, pick one reasonable interpretation). NULL semantics are confusing enough without everyone making their own subtle tweaks. +1 If the standard behavior doesn't support all the functionality we need, we should be looking at PostgreSQL extensions which do not conflict with standard syntax. Supporting standard syntax with different semantics is evil. I have basically two gripes with sql standard treatment of null row values. One is the backward compatibility problem (which extends all the way up to PQgetisnull, and would affect lots of my code) and the other is that you will lose the ability to ever usefully enforce table check constraints over rowtypes like we do for domains (you need to reserve rowtype := null to skirt the issue in plpgsql declarations). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] revision of todo: NULL for ROW variables
Pavel Stehule pavel.steh...@gmail.com writes: I am checking PLpgSQL ToDo topics, and I am not sure if this topic isn't done. And if not, then I would to get some detail. I think that thread petered out because we didn't have consensus on what the behavior ought to be. It goes back to whether there is supposed to be a difference between NULL and ROW(NULL,NULL,NULL,...) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] revision of todo: NULL for ROW variables
On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: I am checking PLpgSQL ToDo topics, and I am not sure if this topic isn't done. And if not, then I would to get some detail. I think that thread petered out because we didn't have consensus on what the behavior ought to be. It goes back to whether there is supposed to be a difference between NULL and ROW(NULL,NULL,NULL,...) I think somewhere along the line it was noticed that SQL says you are supposed to treat (null, null) as null and the behavior of 'is null' operator was changed to reflect this while other null influenced behaviors were left intact (for example, coalesce()). My take on this is that we are stuck with the status quo. If a change must be done, the 'is null' change should be reverted to un-standard behavior. The SQL standard position on this issue is, IMNSHO, on mars. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
