Thread: Small fix for _valueCopy()

Protect against a T_String Value (or other pointer Value) Value
where the pointer is NULL.

If we don't do it, _copyVariableSet() dumps core.

--
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9Index: src/backend/nodes/copyfuncs.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/nodes/copyfuncs.c,v
retrieving revision 1.166
diff -c -p -r1.166 copyfuncs.c
*** src/backend/nodes/copyfuncs.c    2002/03/06 20:34:47    1.166
--- src/backend/nodes/copyfuncs.c    2002/03/07 12:17:35
*************** _copyValue(Value *from)
*** 2571,2577 ****
          case T_Float:
          case T_String:
          case T_BitString:
!             newnode->val.str = pstrdup(from->val.str);
              break;
          default:
              break;
--- 2571,2578 ----
          case T_Float:
          case T_String:
          case T_BitString:
!             if (from->val.str)
!                 newnode->val.str = pstrdup(from->val.str);
              break;
          default:
              break;

Fernando Nasser <fnasser@redhat.com> writes:
> Protect against a T_String Value (or other pointer Value) Value
> where the pointer is NULL.
> If we don't do it, _copyVariableSet() dumps core.

I believe that this change and the corresponding one in equalfuncs
should not be applied.  A Value struct containing a null string
pointer is not a valid node.  (The counterexample showing why
it should not be considered a useful representation of null-ness
is that there'd be no equivalent representation for null integer
Values.)

As with ConstraintsSetStmt, the correct fix is to change the
representation of a SET foo TO DEFAULT command.  Thomas indicated
some interest in handling this detail; if he doesn't get around to
it, I will, or you can.

            regards, tom lane