Can the backend return more than one error message 
Author Message
 Can the backend return more than one error message

Quote:
Tom Lane writes:
> Since there will always be asynchronous conditions to deal with, it'd
> be pretty foolish to design a protocol that assumes that exactly one
> 'E' message will arrive during a PQexec cycle.

Reasonable.

Quote:
> > I am currently looking into extending the protocol so that more fields can
> > be in an ErrorResponse (e.g., error codes).  If this were to happen then
> > we'd need a smarter way of handling more than one error message per cycle.

> Only if you want to overload ErrorResponse so that successive 'E'
> messages mean different things.  I do not think that would be a good
> design.  It'd be better to allow ErrorResponse to carry multiple fields.

That's the idea.  But I can hardly concatenate the error codes, can I?  I
looks as though we need an API where all the messages (errors + notices)
from each query cycle are collected and can be cycled through after
completion.

Quote:
> This'd imply a protocol version bump, but so what?  Changing the
> semantics of ErrorResponse probably ought to require that anyway.

I think I could have done with a minor bump, but if you have some plans,
too, the easier.

--

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.***.com/



Sun, 23 Nov 2003 23:47:16 GMT
 Can the backend return more than one error message

Quote:
Tom Lane writes:
> One way to do this that wouldn't involve breaking the protocol is
> to assign significance to linebreaks in an 'E' message's payload.

Some fields may contain line breaks; for example, error messages
definitely do now.  We could pick a non-printing character (e.g., \001)
as the separator, but it might get ugly with multibyte.  Of course table
names and such things can contain these characters as well, but I guess
there wouldn't be so much resistance in changing that.  At worst we could
make up an escape mechanism.

Quote:
> Also, it would work tolerably well when fed to an old application that
> knows nothing of the convention and just prints out the error string.
> I'm leery of defining a whole new API that must be used before one
> gets to see any of the added error information --- that would mean
> that a lot of people never will see it.

Okay, so PQerrorMessage will print the whole glob, whereas there would be
an accessor method that would filter out the fields.  That would also work
transparently with the notice processor, which I was concerned about until
now.  I like it.

--

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Mon, 24 Nov 2003 00:52:56 GMT
 Can the backend return more than one error message

Quote:
>    ERROR: blah blah
>    CODE: 12345
>    LOCATION: some/file.c line NNN

It might be handy to have the LOCATION in the postmaster log,
or make it something that needs to be explicitly switched on.
I do not think it is of general interest to users (most errors
will result from normal operation, and not bugs that need to be tracked).

Since access to SQLSTATE will become a hot path once savepoints
are available I think that having SQLSTATE up front would be
more convenient.

exec sql insert into blabla values ....;
if (strncmp(sqlca.sqlstate, "23", 2) == 0)    // duplicate key value
        exec sql update blabla set ... ;

Andreas

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Mon, 24 Nov 2003 17:58:33 GMT
 Can the backend return more than one error message

Quote:
Tom Lane writes:
> > Some fields may contain line breaks; for example, error messages
> > definitely do now.

> Yes.  I believe most of them are set up to indent the continuation
> lines, so there wouldn't be much of a problem interpreting the format.

This is not reliable.

(Actually, it's not desirable either.  Think about GUI or web applications
or syslog:  These formatting attempts are meaningless there.  It'd be
better to make error message mostly one-liners and worry about formatting
in the front-ends.  This is not a permanent workaround for the protocol
problems, though.)

Quote:
> In any case, we could say that only a line beginning with a known
> keyword starts a new field.

That would probably require a protocol minor version bump anytime a
keyword is added.  A maintenance pain keeping both sides in sync.

Also, I imagine that with the nature of data that parse tree dumps and
other such debugging info (vacuum verbose?) throw out, it's possible to
have misinterpretations -- or even malicious attacks -- with these scheme.

Quote:

> > Okay, so PQerrorMessage will print the whole glob, whereas there would be
> > an accessor method that would filter out the fields.

I think there will a problem with programs that parse the error messages
in lack of a better idea.  Also, newlines are non-printing sometimes (see
above), so this would produce a glob of garbage.

I think an additional API is necessary.  If you want extra information you
need to ask for it.  In fact, most of the additional information will be
intended to be processed by a program, the error message text is the only
thing humans need to see by default.

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Tue, 25 Nov 2003 00:29:23 GMT
 
 [ 4 post ] 

 Relevant Pages 

1. Can the backend return more than one error message per PQexec?

2. Upgrading the backend's error-message infrastructure

3. Backend error message style issues

4. Upgrading the backend's error-message infrastructure

5. One ODBC, One frontend and three SQL Server backends

6. One ODBC, One frontend and three SQL Server backends

7. Returning system error messages

8. distributed transaction returning error message

9. OLE/DB provider returned message: Protocol error in TDS stream with Linked Server

10. Error message when trying to copy data from one table to another

11. so error message when edit one table in pl/sql

12. Getting Error Message return from a stored procedure!


 
Powered by phpBB® Forum Software