Re: [HACKERS] Undefined psql variables

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Undefined psql variables
Дата
Msg-id CA+TgmoZskdw883be9w5ApnzFxhAv3NpSRFtip-MA=FW2qmt-zw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] Undefined psql variables
Re: [HACKERS] Undefined psql variables
Re: [HACKERS] Undefined psql variables
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] tablesync patch broke the assumption that logical repdepends on?