Re: Old question - failed to find conversion function from
От | Richard Huxton |
---|---|
Тема | Re: Old question - failed to find conversion function from |
Дата | |
Msg-id | 42DD0BB4.6050108@archonet.com обсуждение исходный текст |
Ответ на | Re: Old question - failed to find conversion function from "unknown" ("Ilja Golshtein" <ilejn@yandex.ru>) |
Ответы |
Re: Old question - failed to find conversion function from
|
Список | pgsql-general |
Ilja Golshtein wrote: >>Well, it would obviously be better if PG could figure out it was safe, >>but I'm not sure there's a general case where it is. You can see it's OK >>because you know there's only one row in your SELECT result-set. > > > I think, it's OK because NULL can be compared with anything > with predictable result and no additional information about > types is necessary. > Is it correct vision? Yes*, but you've not got a single NULL in your examples, you've got a set of rows containing one unnamed column with an unspecified type. That set happens to have only one row and that contains a NULL. > I agree it's hard to proceed your query with UNION > and some sort of error is reasonable here. But from outside the brackets, they look the same. What would happen ideally, is that PG would notice we have a single row and column here and collapse this down to a single scalar value. However, I'm not sure under what circumstances it can do so (or does), or whether it is cost-effective. [* Actually, I think NULLs are typed in SQL, which means you should be able to get type violations. ] -- Richard Huxton Archonet Ltd
В списке pgsql-general по дате отправления: