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.
> 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.
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-06-06 15:54:18|
|Subject: Re: Can the backend return more than one error message per PQexec? |
|Previous:||From: KuroiNeko||Date: 2001-06-06 15:45:58|
|Subject: Re: Max inserts / sec ... on any platform?|