Re: Undefined psql variables

2017-04-12 17:05 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > So my view of this is that "send the expression to the server" ought
> > to be just one option for \if, not the only way to do it.
>
> I heartily agree. There should be some kind of client-side expression
> language, and one thing it should allow is calling out to the server.
> Then people who only want to call out to the server can do that, but
> people who want to do something else have the option. Insisting that
> this facility isn't allowed to do anything other than consult the
> server is (1) inconsistent with what we've already got in v10 and (2)
> boxing ourselves into a corner for no very good reason.
>
> Now, the optimal shape for that client-side expression language is not
> very clear to me. Do we want to invent our own language, or maybe
> consider using something that already exists? It's been previously
> suggested that we should somehow embed Lua, and this might not be a
> bad place to consider doing something like that. That might be a way
> to add a lot of power without having to invent an entirely new
> programming language one bit at a time. If we want to invent our own
> expression language, what kind of syntax should it use? Upon what
> kind of design principles should it be based? There's likely to be
> vigorous debate on these topics, and probably also complaints that the
> good designs are too much work and the easy-to-implement designs are
> too limiting. (Regular readers of this mailing list will likely be
> able to guess which side of those debates I'll be on, but we need to
> have them all the same.)
>
>
Integration Lua engine can help lot of - and it can change the design
significantly. For this purpose it is maybe overkill, but it can be fresh
air in psql customisation and usage.

\setlua varname one line lua expression

or

\lua
...
lua code

psqlvar.set("xxxx", somevalue)

\endlua

I like this idea. We can use Math libraries, random generators, ...

If Lua engine and dependency are too strong cafe - very basic calculator
like
https://www.l2f.inesc-id.pt/~david/w/pt/The_YACC_Parser_Generator/Example:_Calculator_with_Variables
can
be good enough (Don't need a variables there)

> Regarding the ostensible topic of this thread, one thought I had while
> reading through these various responses is that the original need
> would be well-served by the (somewhat dubious) syntax that bash uses
> for variable substitution. Obviously, we aren't going to change the
> interpolate-this-variable character from : to $, but bash has
> ${parameter:-word} to substitute a default for an unset parameter,
> ${parameter:=word} to substitute a default for an unset parameter and
> also set the parameter to that value, ${parameter:?word} to error out
> with word as the error mesage if parameter is not set, and so forth.
> If we decide to roll our own, we might consider taking inspiration
> from those constructs.
>
>
It is great and it can work

\set varname :{varname?some error message} ..
\set varname :{varname:-0} ..

Good ideas

Regards

Pavel

> I think that one of the general problems of language design is, as
> Larry Wall once said, that a good language should make simple things
> simple and complex things possible. But simple is not an absolute; it
> depends on context. The things which a language needs to make simple
> are those things which will be done frequently *in that language*. So
> for example in this case, out-calls to SQL need to be very easy to
> write. Maybe the empty-parameter thing needs to be easy; not sure.
> Coming up with a good solution here will involve understanding what
> people typically want to do with a language of this type and then
> making sure that stuff can be done succinctly - and ideally also
> making sure that other stuff is also possible if you're willing to put
> in more legwork.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>