Lists: | pgsql-hackers |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, "Marko Kreen" <markokr(at)gmail(dot)com> |
Subject: | RESET command seems pretty disjointed now |
Date: | 2007-04-15 21:01:49 |
Message-ID: | 22929.1176670909@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
Name
RESET -- restore the value of a run-time parameter to the default value
Synopsis
RESET configuration_parameter
RESET ALL
RESET { PLANS | SESSION | TEMP | TEMPORARY }
That one-line summary has got approximately zip to do with the newly
added options; as does most of the Description section. At the very
least this manual page needs an extensive rewrite. But I wonder whether
the real problem isn't that we chose a bad name for the new commands.
Is there another keyword we could use instead of RESET? A concrete
objection to the current state of affairs is that absolutely anyone,
looking at this set of options with no prior knowledge of PG, would
expect that RESET ALL subsumes all the other cases.
regards, tom lane
From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-16 00:07:54 |
Message-ID: | 4622BE5A.6060101@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> The current documentation for RESET exhibits a certain lack of, um,
> intellectual cohesiveness:
>
> Name
>
> RESET -- restore the value of a run-time parameter to the default value
>
> Synopsis
>
> RESET configuration_parameter
> RESET ALL
> RESET { PLANS | SESSION | TEMP | TEMPORARY }
>
>
> That one-line summary has got approximately zip to do with the newly
> added options; as does most of the Description section. At the very
> least this manual page needs an extensive rewrite. But I wonder whether
> the real problem isn't that we chose a bad name for the new commands.
> Is there another keyword we could use instead of RESET? A concrete
> objection to the current state of affairs is that absolutely anyone,
> looking at this set of options with no prior knowledge of PG, would
> expect that RESET ALL subsumes all the other cases.
Maybe DISCARD for the plans etc might be more intuitive than extending
RESET?
Mark
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | 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-16 23:15:44 |
Message-ID: | 11931.1176765344@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
> Tom Lane wrote:
>> The current documentation for RESET exhibits a certain lack of, um,
>> intellectual cohesiveness:
>>
>> Synopsis
>>
>> RESET configuration_parameter
>> RESET ALL
>> RESET { PLANS | SESSION | TEMP | TEMPORARY }
> Maybe DISCARD for the plans etc might be more intuitive than extending
> RESET?
DISCARD PLANS and DISCARD TEMP seem pretty reasonable, but DISCARD SESSION
sounds a bit odd --- it seems like it might mean "disconnect", which of
course is exactly what we're trying to avoid. But possibly we could
rename RESET SESSION as DISCARD ALL.
Leastwise I haven't got any better ideas. Anyone have another proposal?
regards, tom lane
From: | Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:10:30 |
Message-ID: | 46241076.4050601@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> Tom Lane wrote:
>>> The current documentation for RESET exhibits a certain lack of, um,
>>> intellectual cohesiveness:
>>>
>>> Synopsis
>>>
>>> RESET configuration_parameter
>>> RESET ALL
>>> RESET { PLANS | SESSION | TEMP | TEMPORARY }
>
>> Maybe DISCARD for the plans etc might be more intuitive than extending
>> RESET?
>
> DISCARD PLANS and DISCARD TEMP seem pretty reasonable, but DISCARD SESSION
> sounds a bit odd --- it seems like it might mean "disconnect", which of
> course is exactly what we're trying to avoid. But possibly we could
> rename RESET SESSION as DISCARD ALL.
>
> Leastwise I haven't got any better ideas. Anyone have another proposal?
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.
greetings, Florian Pflug
From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:23:31 |
Message-ID: | 46241383.6060801@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> Tom Lane wrote:
>>> The current documentation for RESET exhibits a certain lack of, um,
>>> intellectual cohesiveness:
>>>
>>> Synopsis
>>>
>>> RESET configuration_parameter
>>> RESET ALL
>>> RESET { PLANS | SESSION | TEMP | TEMPORARY }
>
>> Maybe DISCARD for the plans etc might be more intuitive than extending
>> RESET?
>
> DISCARD PLANS and DISCARD TEMP seem pretty reasonable, but DISCARD SESSION
> sounds a bit odd --- it seems like it might mean "disconnect", which of
> course is exactly what we're trying to avoid. But possibly we could
> rename RESET SESSION as DISCARD ALL.
>
> Leastwise I haven't got any better ideas. Anyone have another proposal?
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.
greetings, Florian Pflug
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 |
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
From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "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, "Neil Conway" <neilc(at)samurai(dot)com> |
Subject: | Re: RESET command seems pretty disjointed now |
Date: | 2007-04-17 07:03:50 |
Message-ID: | e51f66da0704170003w4b6044ffmc385c37e7702264a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 4/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Can't argue with that. Also I don't have better proposals.
If DISCARD is the final word, I start to prepare a patch.
--
marko
From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "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, "Neil Conway" <neilc(at)samurai(dot)com> |
Subject: | Re: RESET command seems pretty disjointed now |
Date: | 2007-04-17 13:34:00 |
Message-ID: | e51f66da0704170634v3104dbdey801b9217ce09cf2f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 4/17/07, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> If DISCARD is the final word, I start to prepare a patch.
Attached patch does following conversions:
RESET PLANS -> DISCARD PLANS
RESET TEMP -> DISCARD TEMP
RESET SESSION -> DISCARD ALL
--
marko
Attachment | Content-Type | Size |
---|---|---|
discard.diff.gz | application/x-gzip | 4.9 KB |
From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | 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-23 20:04:07 |
Message-ID: | 1177358647.16415.140.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.
-Neil
From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Neil Conway" <neilc(at)samurai(dot)com> |
Cc: | "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-24 15:04:19 |
Message-ID: | e51f66da0704240804q59bc280dy4bb129d2eac407fa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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 | Content-Type | Size |
---|---|---|
discard_v2.diff.gz | application/x-gzip | 6.1 KB |
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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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. +
From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | 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:16:35 |
Message-ID: | 1177604195.6440.35.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Tue, 2007-04-24 at 18:04 +0300, Marko Kreen wrote:
> Attached patch addresses all 3 comments. As it will be
> top-level command, I put code into commands/discard.c
Applied with some minor tweaks -- thanks for the patch. I didn't bother
moving the regression tests out of guc.sql, although they don't really
belong there any longer.
-Neil