Re: [GENERAL] Feature request (was psql: absolutes and toggles)

From: Jim Nasby <jim(at)nasby(dot)net>
To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Feature request (was psql: absolutes and toggles)
Date: 2006-09-22 03:50:20
Message-ID: E3A67783-0B31-4CAC-9637-5B98FAA95EE2@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Dropping -general.

On Sep 14, 2006, at 5:33 PM, Steve Crawford wrote:
> I would like the ability to absolutely set parameters/settings in psql
> so that our psql scripts could generate predictable output absent a
> known or controllable initial state. Original discussion at bottom of
> message.
>
> One alternate and easier approach I've thought of is to simply add
> something akin to a \factory-reset meta-command which would return all
> settings to the state they would be in immediately after starting psql
> with the --no-psqlrc option. This would at least provide one
> solution to
> the problem and might be a handy meta-command even if absolute
> settings
> were added.
>
> If a "factory reset" meta-command were added I think that \o should be
> exempted as it is already an absolute setting that can be predictably
> used in scripts and, where output redirection isn't specified in the
> script, we shouldn't interfere with the ability to save the output
> of a
> script or scripts as the user desires.

I remember some discussion about a connection-level reset, but I
don't think it would apply to psql.

Another way to deal with this would be to add a command that allows
you to definitively set any setting, ie:

\set timing = on

I can see value in both options.

BTW, it probably wouldn't be terribly difficult to figure out how to
do the \set option. You'd have to see how commands 'plug in' to the
interface (just look at any other command as an example, preferably
one that takes an option), and see how options are actually set (ie:
look at \timing). Coming up with a partial patch and asking for help
is likely to get this done a lot sooner than just sticking it on the
TODO.

> Peter Eisentraut wrote:
>> Steve Crawford wrote:
>>> We create psql scripts that can be used at various times by various
>>> users. I have been unable to find how to absolutely set various
>>> options (timing, expanded, etc.) rather than toggle them.
>
>>> The --no-psqlrc option provides a partial workaround - as long as
>>> the user remembers to include it and as long as they are only
>>> running the one script. But if they forget or if they are already
>>> running a session there is no telling what settings have been
>>> toggled by previously run scripts or the users themselves.
>
>>> So...have I overlooked an interactive psql option that will let me
>>> reset all options to "factory-defaults" or a method of specifying an
>>> absolute setting to the various options?
>>
>> Probably not.
>>
>>> If not, do psql users out there feel this is worth a feature
>>> request?
>>
>> I think so.
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Jim Nasby jimn(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jim Nasby 2006-09-22 03:53:06 Re: The Best Postgresql Load Balancing Solution
Previous Message Jim Nasby 2006-09-22 03:43:44 Re: Sun Java Studio Creator and PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-22 05:06:09 Re: pg_upgrade: downgradebility
Previous Message Jim Nasby 2006-09-22 03:39:16 Re: Optimising a query requiring seqscans=0