Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 8964b41

Browse files
author
Neil Conway
committed
Remove a 15-year old comment questioning behavior that is now well-
established: referencing an undefined parameter should result in an error, not NULL.
1 parent 9b3aee5 commit 8964b41

File tree

1 file changed

+1
-6
lines changed

1 file changed

+1
-6
lines changed

src/backend/executor/execQual.c

Lines changed: 1 addition & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.197 2006/11/06 18:21:31 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.198 2006/11/08 00:45:30 neilc Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -595,11 +595,6 @@ ExecEvalConst(ExprState *exprstate, ExprContext *econtext,
595595
* something like ($.name) and the expression context contains
596596
* the current parameter bindings (name = "sam") (age = 34)...
597597
* so our job is to find and return the appropriate datum ("sam").
598-
*
599-
* Q: if we have a parameter ($.foo) without a binding, i.e.
600-
* there is no (foo = xxx) in the parameter list info,
601-
* is this a fatal error or should this be a "not available"
602-
* (in which case we could return NULL)? -cim 10/13/89
603598
* ----------------------------------------------------------------
604599
*/
605600
static Datum

0 commit comments

Comments
 (0)