Re: Planning incompatibilities for Postgres 10.0

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planning incompatibilities for Postgres 10.0
Date: 2013-05-28 21:18:28
Message-ID: 20130528211828.GC26313@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 27, 2013 at 05:21:16PM -0700, Joshua D. Drake wrote:
>
> On 05/27/2013 04:58 PM, Craig Ringer wrote:
> >
> >On 05/28/2013 12:41 AM, Simon Riggs wrote:
> >>I'm happy with that.
> >>
> >>I was also thinking about collecting changes not related just to disk
> >>format, if any exist.
> >Any wire protocol or syntax changes?
> >
> >I can't seem to find a "things we want to do in wire protocol v4" doc in
> >the wiki but I know I've seen occasional discussion of things that can't
> >be done without protocol changes. Anyone with a better memory than me
> >able to pitch in?
> >
> >What'd be required to support in-band query cancellation? Sending
> >per-statement GUCs (to allow true statement timeout)?
> >
>
> I would like to see the ability to define if a query is read only at
> the protocol level, so that load balances that speak libpq can know
> what to do with the query without parsing it.

Sounds nice, but how would we do that? That would require libpq to know
it, right? Do we pass anything back after parsing but before execution?
Could it be optional? What about functions that modify the database
--- isn't that only known at execution time?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-05-28 21:20:02 Re: Planning incompatibilities for Postgres 10.0
Previous Message Bruce Momjian 2013-05-28 21:11:05 Re: Planning incompatibilities for Postgres 10.0