Re: unknownin/out patch

Joe Conway <mail(at)joeconway(dot)com> writes:
>> Here's a patch to add unknownin/unknownout support. I also poked around
>> looking for places that assume UNKNOWN == TEXT. One of those was the
>> "SET" type in pg_type.h, which was using textin/textout. This one I took
>> care of in this patch. The other suspicious place was in
>> string_to_dataum (which is defined in both selfuncs.c and indxpath.c). I
>> wasn't too sure about those, so I left them be.

I do not think string_to_datum is a problem. UNKNOWN constants should
never get past the parse analysis stage, so the planner doesn't have to
deal with them. Certainly, it won't be looking at them in the context
of making any interesting selectivity decisions.

> I found three other suspicious spots in the source, where UNKNOWN ==
> TEXT is assumed. The first looks like it needs to be changed for sure,
> the other two I'm less sure about. Feedback would be most appreciated
> (on this and the patch itself).

> (line numbers based on CVS from earlier today)
> parse_node.c
> line 428
> parse_coerce.c
> line 85
> parse_coerce.c
> line 403

The first two of these certainly need to be changed --- these are
exactly the places where we convert literal strings to and (later)
from UNKNOWN-constant representation. The third is okay as-is;
it's a type resolution rule, not code that is touching any literal
constants directly. Will fix these in an upcoming commit.

The patch looks okay otherwise, except that I'm moving the typedef
unknown and the fmgr macros for it into varlena.c. These two routines
are the only routines that will ever need them, so there's no need to
clutter the system-wide headers with 'em. (Also, I am uncomfortable
with having a globally-visible typedef with such a generic name as
"unknown"; strikes me as a recipe for name conflicts.)

regards, tom lane