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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Failure to coerce unknown type to specific type
Date: 2015-04-23 09:22:27
Message-ID: CAKFQuwZAmCHjOnpc758+74Fc8dR4JwU1+V5LLr8uV3UOwzJt6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Wednesday, April 22, 2015, Jeff Davis <pgsql(at)j-davis(dot)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

http://www.postgresql.org/message-id/55244654.7020405@BlueTreble.com
http://www.postgresql.org/message-id/flat/CAKFQuwazck37J7fA4pZOz8m9JsKMQQoPAftxRY0cA_n4R2xfbQ(at)mail(dot)gmail(dot)com#CAKFQuwazck37J7fA4pZOz8m9JsKMQQoPAftxRY0cA_n4R2xfbQ@mail.gmail.com

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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2015-04-23 09:26:16 Re: [BUGS] Failure to coerce unknown type to specific type
Previous Message David G. Johnston 2015-04-23 08:49:38 Re: [BUGS] Failure to coerce unknown type to specific type

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2015-04-23 09:26:16 Re: [BUGS] Failure to coerce unknown type to specific type
Previous Message Pavel Stehule 2015-04-23 08:56:00 Re: PL/pgSQL, RAISE and error context