Re: assertion failure w/extended query protocol
Rushabh Lathia <rushabh.lathia@gmail.com>
From: Rushabh Lathia <rushabh.lathia@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Peter Geoghegan <peter@2ndquadrant.com>
Date: 2012-10-22T05:24:03Z
Lists: pgsql-hackers
Attachments
- assertion_pg.patch (application/octet-stream) patch
Sorry It might be late here, but just wanted to share the patch I came up with. Actually with Robert told he reported issues to pgsql-hacker, I thought he might have also submitted patch. PFA I came up with, but seems like issue has been already committed. Thanks, On Sat, Oct 20, 2012 at 9:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On Saturday, October 20, 2012 12:05:15 AM Tom Lane wrote: > >> (such as the current query showing up in pg_cursors --- maybe we should > >> prevent that?) > > > I don't really see an argument for preventing that. > > Well, the reason it seems peculiar to me is that the current query is in > no way a cursor --- it's just a SELECT in the cases that showed > regression test differences. I didn't go looking in the code yet, but > I suspect the pg_cursors view is displaying all Portals. Arguably, it > should only display those that were created by actual cursor commands. > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Rushabh Lathia
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