Re: [BUGS] Failure to coerce unknown type to specific type

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [BUGS] Failure to coerce unknown type to specific type
Дата
Msg-id CAKFQuwZAmCHjOnpc758+74Fc8dR4JwU1+V5LLr8uV3UOwzJt6g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUGS] Failure to coerce unknown type to specific type  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Wednesday, April 22, 2015, Jeff Davis <pgsql@j-davis.com> wrote:
On Wed, 2015-04-22 at 20:35 -0700, David G. Johnston wrote:

> ​My gut reaction is if you feel strongly enough to add some additional
> documentation or warnings/hints/details related to this topic they
> probably would get put in; but disallowing "unknown" as first-class
> type is likely to fail to pass a cost-benefit evaluation.

I'm not proposing that we eliminate unknown. I just think columnrefs and
literals should behave consistently. If we really don't want unknown
columnrefs, it seems like we could at least throw a better error.

We do allow unknown column refs.  We don't allow you to do much with them though - given the lack of casts, implicit and otherwise.  The error that result from that situation are where the complaint lies.  Since we cannot disallow unknown column refs the question is can the resultant errors be improved.  I really don't see value in expending effort solely trying to improve this limited situation.  If the same effort also improves a wider swath of the code base then great.


​Slightly tangential but a pair of recent threads 


where I pondered about polymorphic functions got me thinking about the following function definition:

create function poly(inarg anyelement, testarg unknown) returns anyelement
AS $$
BEGIN
   SELECT inarg;
END;
$$
LANGUAGE plpgsql
;

Which indeed works...

Jim's "variant" type largely mirrors the behavior desired in this thread.

The lack of casting fails to unknown makes it an unsuitable alternative for "variant" though maybe if indeed we allow type coercion to work it would become viable.  But the same concerns apply as well.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL, RAISE and error context
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: [BUGS] Failure to coerce unknown type to specific type