Re: RESET command seems pretty disjointed now

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, pgsql-hackers(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>
Subject: Re: RESET command seems pretty disjointed now
Date: 2007-04-17 00:24:41
Message-ID: 12461.1176769481@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com> writes:
> Tom Lane wrote:
>>> The current documentation for RESET exhibits a certain lack of, um,
>>> intellectual cohesiveness:

> What about
> RESET parameter
> RESET { PLANS | TEMP | TEMPORARY }
> RESET ALL { PARAMETERS | STATE }

> RESET ALL would become an abbreviation of RESET ALL PARAMETERS (for backwards
> compatibility), while RESET SESSION would be renamed to RESET ALL STATE.

This doesn't do anything to address the lack of coherence. It's not
only that backward compatibility forces us to break the clear meaning of
ALL; another problem is that we break the symmetry between SET, RESET,
and SHOW. If you can RESET SESSION, what does it mean to SET SESSION?
Or SHOW SESSION?

Given the precedent that RESET ALL only resets GUC variables, I think
it's probably best if we just say that RESET only affects GUC variables,
period. The new functionality should go by another name entirely.
I'm not wedded to DISCARD by any means, but I do not believe that
changing some words after RESET is going to fix my complaint.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-04-17 00:57:02 Re: Hacking on PostgreSQL via GIT
Previous Message Florian G. Pflug 2007-04-17 00:23:31 Re: RESET command seems pretty disjointed now