Re: unclear enum error messages

There are a few error messages like this in the code:

/*
* We rely on being able to get the specific enum type from the calling
* expression tree. The generic type mechanism should have ensured that
* both are of the same type.
*/
enumtypoid = get_fn_expr_argtype(fcinfo->flinfo, 0);
if (enumtypoid == InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("could not determine actual enum type")));

First, isn't this an internal error?

What is an actual enum type? And how should a user react if he got this
message? I would ask, "why not?".

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> There are a few error messages like this in the code:
> /*
> * We rely on being able to get the specific enum type from the calling
> * expression tree. The generic type mechanism should have ensured that
> * both are of the same type.
> */
> enumtypoid = get_fn_expr_argtype(fcinfo->flinfo, 0);
> if (enumtypoid == InvalidOid)
> ereport(ERROR,
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("could not determine actual enum type")));

> First, isn't this an internal error?

Not necessarily; there are many code paths by which a function could get
called without argument-type info. Thus the FEATURE_NOT_SUPPORTED
classification.

> What is an actual enum type? And how should a user react if he got this
> message? I would ask, "why not?".

Yeah, I would too, but without a concrete example to look at it's hard
to say if the situation could be improved.

regards, tom lane

On Nov 28, 2007 11:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > What is an actual enum type? And how should a user react if he got this
> > message? I would ask, "why not?".
>
> Yeah, I would too, but without a concrete example to look at it's hard
> to say if the situation could be improved.

Hmm. I've just tried, unsuccessfully, to trigger that branch both
calling those functions directly from psql and from plpython calling
plpy.prepare() and passing bogus type info in. It's harder than it
looks. I'm sure that there are code paths that will call those
functions without filling out that type info (e.g. from C user defined
function?), but they must surely fall outside of the expected use
cases. Hence the error code is probably correct. Unsure about the
message... we could make it extremely explicit e.g. "you're calling
this without filling in fcinfo" but we'd want to be really sure that
it's definitely only possible to trigger via user error before getting
that detailed. I'm not sure that we're completely confident of that,
so perhaps the vague-ish message is ok.

I wouldn't get too worried, though. These are defensive error messages
that are really just checking for sane input, and they seem difficult
to deliberately trip, let alone accidentally, so stressing about them
is probably unnecessary.

Cheers

Tom

"Tom Dunstan" <pgsql(at)tomd(dot)cc> writes:
> I wouldn't get too worried, though. These are defensive error messages
> that are really just checking for sane input, and they seem difficult
> to deliberately trip, let alone accidentally, so stressing about them
> is probably unnecessary.

Right. I'm not really expecting to see that message fire; it's just
there to ensure sane behavior if it does happen. Peter might be right
that an elog instead of ereport would be sufficient.

regards, tom lane