Re: psql setenv command

From: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql setenv command
Date: 2011-11-20 16:07:07
Message-ID: CAK3UJRG3qwmgDrqV47pKh1uGde3rhe6AQmUNf9dniKX3as_mmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Updated patch is attached - adding to Nov commitfest.

Review of the v2 patch:

* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
some tab characters being used in psql-ref.sgml where they shouldn't
be.

* Usability Review
I sort of doubt I'll use the feature myself, but there was at least
one +1 for the feature idea already, so it seems useful enough. That
said, the stated motivation for the patch:

> First, it would be useful to be able to set pager options and possibly other
> settings, so my suggestion is for a \setenv command that could be put in a
> .psqlrc file, something like:

seems like it would be more suited to being set in the user's
~/.profile (perhaps via an 'alias' if you didn't want the changes to
apply globally). So unless I miss something, the real niche for the
patch seems to be for people to interactively change environment
settings while within psql. Again, not something I'm keen on for my
own use, but if others think it's useful, that's good enough for me.

* Coding Review / Nitpicks
The patch implements \setenv via calls to unsetenv() and putenv(). As
the comment notes,

| That means we
| leak a bit of memory here, but not enough to worry about.

which seems true; the man page basically says there's nothing to be
done about the situation.

The calls to putenv() and unsetenv() are done without any real input
checking. So this admittedly-pathological case produces surprising
results:

test=# \setenv foo=bar baz
test=# \! echo $foo
bar=baz

Perhaps 'envvar' arguments with a '=' in the argument should just be
disallowed.

Also, should the malloc() of newval just use pg_malloc() instead?

* Reviewer Review
I haven't tested on Windows.

Josh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-11-20 16:33:47 Re: testing ProcArrayLock patches
Previous Message Noah Misch 2011-11-20 13:05:26 Re: [PATCH] Support for foreign keys with arrays