Re: [HACKERS] Undefined psql variables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Undefined psql variables
Date
Msg-id CA+TgmoZskdw883be9w5ApnzFxhAv3NpSRFtip-MA=FW2qmt-zw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] Undefined psql variables  (Corey Huinker <corey.huinker@gmail.com>)
Re: [HACKERS] Undefined psql variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Thu, Apr 13, 2017 at 8:56 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> Calling the server is already available:
>
>   SELECT <whatever> AS varname \gset

Sure, but people are going to want to do it inline with the \if.
Anything that can be done that way can also be done this way, but
people will want it just to make the code look nicer.   I don't think
we should restrict \if to be ONLY an SQL callout, but if people want
that as an option, and I bet they do, then I think we should give it
to them.

> I somewhat disagree: Does building postgres should depend on lua? I think
> adding such a mandatory dependency would not be a good idea. If it is not
> mandatory, then it would mean that psql could be compiled with or without
> lua embedding, thus psql would not be dependable because features may or may
> not be available when writing a "psql script".

That's true, but you could say the same thing about SSL or NLS.  In
practice, any vendor distribution of PostgreSQL will be built with
those options even though, for good reason, they are not hard
dependencies.  I don't see why this should be any different, assuming
the dependency is something that those vendors are for the most part
already packaging anyway.

> Does programming as such in psql is such a good idea?

I think we've pretty much crossed that line already with \if.

> ISTM that cpp-like capabilities (include, if, variables, some expressions)
> are somewhat both useful and enough for the limited use cases I have
> encountered. Similar languages are offered in other instances, such as
> readline inputrc or vim vimrc.

Yeah, but nobody would claim that cpp is a fun thing to program with,
and it's pretty clear from discussions here that some people are
squeezing last possible bit of juice out of every existing facility
and still wanting more.  I don't think it's likely that adding one or
two additional simple constructs is going to be sufficient to keep
people from wanting more.  I mean, I would have switched to Perl and
DBD::Pg rather than write some of the crazy psql scripts that have
been posted here, but we're not building PostgreSQL to meet my needs
particularly.

> I suggest to reuse pgbench expression engine, developed by Haas Robert:-)

Not a bad idea (though I'm sure there are other reasonable options, too).

> Generating a error message with ${foo:?} is nice, but what psql need is just
> a way to test whether a variable is defined or not.

I'm not saying we should slavishly follow bash, but don't confuse what
you need with what other people need.  bash (well, sh, really) grew
that syntax for a reason, and it may be more than "there was this one
guy back in the seventies who wanted it, and ...".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?