Re: Planning incompatibilities for Postgres 10.0

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Planning incompatibilities for Postgres 10.0
Дата
Msg-id 20130528211828.GC26313@momjian.us
обсуждение исходный текст
Ответ на Re: Planning incompatibilities for Postgres 10.0  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: Planning incompatibilities for Postgres 10.0
Re: Planning incompatibilities for Postgres 10.0
Список 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
thatmodify the database
 
--- isn't that only known at execution time?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Planning incompatibilities for Postgres 10.0
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Planning incompatibilities for Postgres 10.0