Skip site navigation (1) Skip section navigation (2)

Re: RESET command seems pretty disjointed now

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RESET command seems pretty disjointed now
Date: 2007-04-26 16:15:15
Message-ID: 200704261615.l3QGFFj19696@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Patch applied from Neil.

---------------------------------------------------------------------------

Marko Kreen wrote:
> On 4/23/07, Neil Conway <neilc(at)samurai(dot)com> wrote:
> > On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
> > > Attached patch does following conversions:
> >
> > ISTM it would be cleaner to use an enum to identify the different
> > variants of the DISCARD command, rather than a character string.
> >
> > Is guc.c still the logical place for the implementation of DISCARD?
> > Something under backend/commands might be better, although I don't see a
> > real obvious place for it.
> >
> > The psql tab completion code requires updating for the new DISCARD
> > command.
> 
> Attached patch addresses all 3 comments.  As it will be
> top-level command, I put code into commands/discard.c
> 
> -- 
> marko

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

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

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Neil ConwayDate: 2007-04-26 16:16:35
Subject: Re: RESET command seems pretty disjointed now
Previous:From: Tom LaneDate: 2007-04-26 14:39:28
Subject: Re: Avoiding unnecessary reads in recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group