Thread: 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 generictype 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 enumtype"))); 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@gmx.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@sss.pgh.pa.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@tomd.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