Re: DISTINCT with NULLs and INT fields

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "George Pavlov" <gpavlov(at)mynewplace(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: DISTINCT with NULLs and INT fields
Date: 2005-12-28 20:46:29
Message-ID: 21699.1135802789@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"George Pavlov" <gpavlov(at)mynewplace(dot)com> writes:
> indeed! but, wait, doesn't our favorite dbms do some implicit casting
> too? continuing with my table foo (a varchar, b int):

> test=# delete from foo;
> DELETE 2
> test=# insert into foo values (4,4);
> INSERT 0 1
> test=# insert into foo values ('4','4');
> INSERT 0 1
> test=# insert into foo values ('oh','no');
> ERROR: invalid input syntax for integer: "no"

Sure, but in this example the required type of the value is clear from
immediate context (ie, the INSERT). This is one of the cases where
the SQL spec requires a bare NULL to be accepted. (BTW, 'no' and '4'
in this example are *not* values of type text; they are untyped literals
which we eventually resolve as varchar or int.)

The other case you mentioned is one where we are going out on a limb a
bit:

INSERT INTO foo SELECT NULL, NULL;

In this case we allow the SELECT to not force a type choice, so that the
INSERT sees the raw untyped values, but I think that this query is
probably illegal per spec --- I believe the spec requires a SELECT to
deliver well-defined data types. Too lazy to go look up chapter and
verse at the moment.

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message George Pavlov 2005-12-28 21:04:10 Re: DISTINCT with NULLs and INT fields
Previous Message George Pavlov 2005-12-28 20:37:29 Re: DISTINCT with NULLs and INT fields