Re: ambiguous sql states

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Dave Cramer <dave(at)fastcrypt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ambiguous sql states
Date: 2003-08-24 21:27:28
Message-ID: 1027.1061760448@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-08-24 21:37:14 Re: [SQL] "SELECT IN" Still Broken in 7.4b
Previous Message Peter Eisentraut 2003-08-24 21:24:50 Re: ambiguous sql states