Sam Mason wrote:
> Hum, there seem to be lots of different things happening here--lets try
> and untangle them a bit. I would say that the following returns a null
> value of type row (actually a pair of integers):
>
> SELECT b
> FROM (SELECT 1) a
> LEFT JOIN (SELECT 1,2) b(b1,b2) ON FALSE;
>
> It currently gets serialized as '\N' in the output of psql for me, but
> I'd have no problem if it appeared as '(,)'. Both of these seem like
> valid representations of a null row to me.
If we query that result with libpq functions, it appears that the result is a
row that contains a field named "b" of type record (oid=2249), and that field
is null.
So if we consider that this field is a row, then yeah it's a null row.
> In other discussions about similar issues I've said that the expression:
>
> ROW(NULL,NULL) IS DISTINCT FROM NULL
>
> should evaluate to FALSE. I still think this is correct and generally
> useful behavior.
I see no reason to disagree with this. Besides, the fact that
ROW(NULL,NULL) IS DISTINCT FROM NULL evaluates to true
while ROW(NULL,NULL) IS NULL also evaluates to true
looks quite puzzling to me.
> > However, I agree that if we consider that a row is a composite type, then
> > there is a problem because we sure can insert NULL into a column that is of a
> > composite type. So the "row cannot be null" line of reasoning holds only so
> > far as you don't stuff rows into columns :)
>
> When you say "columns", do you mean the value associated with a
> particular attribute in a particular row of a particular table?
That's what I meant, yes.
Best regards,
--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org