Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> The sorts of watered-down half-features being proposed here are not
> going to do anything to address that situation. If there are
> restrictions on what GUCs can be changed with this feature, or if the
> feature is disabled by default, or if you can only use it when the
> moon is full and you hop on your left foot while spinning around
> sideways, then pgAdmin (and any other, similar tools) are just going
> to keep doing what they do today in the same crappy, unsafe way they
> currently do it. Meanwhile, people who use psql are going to continue
> to find themselves without a reasonable API for doing the same thing
> that can be done easily using pgAdmin.

To be honest, I don't find the arguments of "pgAdmin does it badly"
nor "psql users want this ability" (which I find difficult to believe)
to be particularlly compelling reasons to have a dangerous
implementation (even if it's better than 'adminpack' today) in core.

If it's in core rather than in contrib it's going to be deployed a great
deal farther with a large increase in userbase. I've already stated
that if this is in contrib that my concerns are much less.

> I think the goals of this patch should be to (1) let users of other
> clients manipulate the startup configuration just as easily as we can
> already do using pgAdmin,

Which could be done already through use of adminpack.. The capabilities
exposed there could be used by other clients. The fact that none of the
other clients have chosen to do so could be an indication that this
ability isn't terribly 'in demand'.

> and (2) remove some of the concurrency
> hazards that pgAdmin introduces, for example by using locking and
> atomic renames.

Why can't adminpack do that..?

> Restricting the functionality to something less than
> what pgAdmin provides will just cause people to ignore the new
> mechanism and use the one that already exists and, by and large,
> works. And trying to revise other aspects of how GUCs and config
> files work as part of this effort is not reasonably related to this
> patch, and should be kept out of the discussion.

We're talking about modifying config files through an interface and you
wish to exclude all discussion about how those config files are handled.
That leads to a result that only an adminpack-like solution is an
option, to which I respond "use and improve adminpack then". If we want
something that works well in *core* then I don't think we can exclude
how core reads and handles config files from the discussion. We need a
real solution, not another adminpack-like hack.

Thanks,

Stephen