Re: enhanced error fields - Mailing list pgsql-hackers

From Tom Lane
Subject Re: enhanced error fields
Date
Msg-id 9897.1356710225@sss.pgh.pa.us
Whole thread Raw
In response to Re: enhanced error fields  (Stephen Frost <sfrost@snowman.net>)
Responses Re: enhanced error fields  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> To be honest, I haven't been following this thread at all, but I'm kind
> of amazed that this patch seems to be progressing.  I spent quite a bit
> of time previously trying to change the CSV log structure to add a
> single column and this patch is adding a whole slew of them.

I don't think that part's been agreed to at all; it seems entirely
possible that it'll get dropped if/when the patch gets committed.
I'm not convinced that having these fields in the log is worth
the compatibility hit of changing the CSV column set.

> As regards this specific patch, I trust that the protocol error response
> changes won't have any impact on existing clients?  Do we anticipate
> something like the JDBC driver having any issues?  If there's any chance
> that we're going to break a client by sending it things which it won't
> understand, it seems we'd need to bump the protocol (which hasn't been
> done in quite some time and would likely needs its own discussion...).

I think we are okay on this.  The protocol definition has said from the
very beginning "Since more field types might be added in future,
frontends should silently ignore fields of unrecognized type".  A client
that fails to do that is buggy, not grounds for bumping the protocol.

I haven't been following the patch so have no thoughts about your
other comments.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Behaviour of bgworker with SIGHUP
Next
From: Pavel Stehule
Date:
Subject: proposal: ANSI SQL 2011 syntax for named parameters