database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Clean up handling of explicit NULL constants. Cases like

Browse Source 
SELECT null::text;
	SELECT int4fac(null);
work as expected now.  In some cases a NULL must be surrounded by
parentheses:
	SELECT 2 + null;                 fails
	SELECT 2 + (null);               OK
This is a grammatical ambiguity that seems difficult to avoid.  Other
than that, NULLs seem to behave about like you'd expect.  The internal
implementation is that NULL constants are typed as UNKNOWN (like
untyped string constants) until the parser can deduce the right type.
This commit is contained in:
Tom Lane
1999-12-24 06:43:34 +00:00
parent bd5ea42a8d
commit 350cb386af
4 changed files with 67 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/nodes/equalfuncs.c
View File

@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/nodes/equalfuncs.c,v 1.53 1999/12/13 01:26:53 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/nodes/equalfuncs.c,v 1.54 1999/12/24 06:43:32 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -144,6 +144,13 @@ _equalConst(Const *a, Const *b)
if (a->constbyval != b->constbyval)
return false;
/* XXX What about constisset and constiscast? */
/*
* We treat all NULL constants of the same type as equal.
* Someday this might need to change? But datumIsEqual
* doesn't work on nulls, so...
*/
if (a->constisnull)
return true;
return (datumIsEqual(a->constvalue, b->constvalue,
a->consttype, a->constbyval, a->constlen));
}