Re: ambiguous sql states

Specifically, if you try to open a file for copy, and it isn't there it
will return

int
errcode_for_file_access(void)
{

case ENOENT: /* No such file or
directory */
edata->sqlerrcode = ERRCODE_UNDEFINED_OBJECT;
break;

Dave

On Sat, 2003-08-23 at 15:42, Peter Eisentraut wrote:

Dave Cramer writes:

I'm working on identifying various errors in ecpg using sql state and
one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
file which isn't found. This is returned in a number of places. Is it
possible to get a set of file specific error codes?

That error code if for undefined objects, not files that can't be found.
Can you identify the cases you are concerned about?

--
Dave Cramer <dave@fastcrypt.com>
fastcrypt

Peter Eisentraut <peter_e@gmx.net> writes:

Dave Cramer writes:

I'm working on identifying various errors in ecpg using sql state and
one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
file which isn't found. This is returned in a number of places. Is it
possible to get a set of file specific error codes?

That error code if for undefined objects, not files that can't be found.

Dave's correct, that's what we're currently using. I'm happy to change
it if someone can suggest an appropriate SQLSTATE (even a category...)
to use instead.

I would however like to know why ecpg cares.

regards, tom lane

Tom,

The reason it is of importance to me/ecpg is for informix compatibility.

informix returns a unique errorcode for the copy operation when the file
is not found. this isn't much of an argument from a postgres POV,
however I still find the sqlstate to be ambiguous.

Dave

On Sun, 2003-08-24 at 16:46, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Dave Cramer writes:

I'm working on identifying various errors in ecpg using sql state and
one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
file which isn't found. This is returned in a number of places. Is it
possible to get a set of file specific error codes?

That error code if for undefined objects, not files that can't be found.

Dave's correct, that's what we're currently using. I'm happy to change
it if someone can suggest an appropriate SQLSTATE (even a category...)
to use instead.

I would however like to know why ecpg cares.

regards, tom lane

--
Dave Cramer <dave@fastcrypt.com>
fastcrypt

Tom Lane writes:

Dave's correct, that's what we're currently using. I'm happy to change
it if someone can suggest an appropriate SQLSTATE (even a category...)
to use instead.

I had a private chat with Dave about this. It was my view that a missing
file that is read by a backend COPY is indistinguishable from, say, a
missing table or trigger, as far as recovery options by the client
application are concerned.

I would however like to know why ecpg cares.

It doesn't. This is related to an Informix porting project, which
apparently has a separate error code for its LOAD command. Why exactly
that would affect our COPY isn't totally clear to me.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

I had a private chat with Dave about this. It was my view that a missing
file that is read by a backend COPY is indistinguishable from, say, a
missing table or trigger, as far as recovery options by the client
application are concerned.

Hm. One problem in this area is that a file-not-found error could be a
user error (if the user-specified name in COPY or lo_import() or some
such is not found). Or it could be a Postgres internal error (if a file
internal to the database can't be found). I'm not sure it's real
practical to distinguish these cases in the code, unfortunately ---
unless people are excited enough about it to invent
errcode_for_user_file_access() as distinct from
errcode_for_file_access(). (Even if we wanted to do this, I'm unsure
how far up the changes might need to propagate.)

In either case, though, it is arguable that it's not appropriate to put
it under the "syntax error" SQLSTATE category.

regards, tom lane