Skip site navigation (1) Skip section navigation (2)

Re: unclear enum error messages

From: "Tom Dunstan" <pgsql(at)tomd(dot)cc>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: unclear enum error messages
Date: 2007-11-29 05:28:13
Message-ID: ca33c0a30711282128p5af362bcye4ac47d5cba9a01b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-11-29 05:32:18
Subject: Re: unclear enum error messages
Previous:From: Gregory StarkDate: 2007-11-29 03:34:16
Subject: Re: How to write a c-function to return multiple bytea rows

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group