NAB : insert into <table> select distinct <fields> => when used on null, distinct causes loss of type knowledge
Hi,
Not exactly a showstopper, but I noticed this behaviour:
db=# create table f1 (id int, value int);
CREATE TABLE
db=# insert into f1 select 1 as id, null;
INSERT 25456306 1
db=# insert into f1 select distinct 2 as id, null;
ERROR: column "value" is of type integer but expression is of type text
HINT: You will need to rewrite or cast the expression.
db=# insert into f1 select distinct on (id) 2 as id, null;
INSERT 25456307 1
So it seems distinct applied to the second column causes it to lose knowledge
on its type.
Does anybody happen to know why ?
--
Best,
Frank.
Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
So it seems distinct applied to the second column causes it to lose knowledge
on its type.
No, because it never had any: NULL is typeless (type UNKNOWN, to the
parser). In the straight INSERT this doesn't matter because we don't
have to resolve the type until we get up to the INSERT, and then we know
we want to insert into the value column. But to do a DISTINCT, the
parser has to assign datatypes to all the columns (to determine the
comparison rules). The default assumption for an UNKNOWN constant is
type TEXT. This is chosen based on the assumption that when someone
writes
select distinct 'foo';
they are probably expecting the system to treat 'foo' as a TEXT literal.
regards, tom lane
Hi Tom,
No, because it never had any: NULL is typeless (type UNKNOWN, to the
parser). But to do a DISTINCT, the parser has to assign datatypes to all the
columns (to determine the comparison rules). The default assumption for an
UNKNOWN constant is type TEXT.
I grok, thanks for the quick reply.
--
Best,
Frank.