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.
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.
