Re: assertion failure w/extended query protocol
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Peter Geoghegan <peter@2ndquadrant.com>
Date: 2012-10-20T02:19:11Z
Lists: pgsql-hackers
On 10/19/2012 09:05 PM, Robert Haas wrote: > On Fri, Oct 19, 2012 at 6:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> It's hard to visualize a use for this except for testing purposes, but >> that might be sufficient reason to have it. One thing that would be >> pretty cool is to be able to run the regression tests in extended >> protocol. > Yes, indeed. We came up with an even grottier hack to do this > internally for our fork and found a couple of bugs. It appears, for > example, that the extended protocol exercises copyfuncs/equalfuncs > support a bit better than the simple protocol, and that's certainly > something that would be good to exercise regularly. > > What I think is a bit insidious about this whole thing is that the > libpq documentation is not very clear about which functions use the > simple protocol and which ones use the extended protocol; it basically > treats that as an internal implementation detail. And in theory it > should be, but there are significant performance differences between > the two and, as we're now finding out, they're not bug-compatible > either. So +1 from me on finding a way to make the regression tests > run under the extended protocol. If we do that, we should certainly > make sure the buildfarm does it regularly, because otherwise it's > quite likely to get broken again without anyone noticing. Put this feature in psql and I'll try to take care of the rest. cheers andrew
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
- 9dbf2b7d75de 9.2.0 cited