Re: Desirability of client-side expressions in psql?

Hello Stephen,

> [...] So, I tend to agree w/ Andrew that while this is a good topic to
> have on -hackers, it shouldn't be a CF entry. I wouldn't draw any
> conclusions from Andrew closing it out as "not appropriate for CF".

Sure. As I had no committer feedback on the discussion for 3 months, I
tried this as an ineffective way to get some. It did not work up to now.

>> As I have not received feedback from committers about the desirability of
>> the feature, I interpret that as "the feature is not desirable", and I will
>> not develop it, because of the probability that this would be time down the
>> drain.
>
> Personally, I'm definitely in favor of having a lot more flexibility and
> capability in psql, that's an area which I think we don't focus on
> nearly enough. Having to fight with bash or another language to make
> calls to psql to get things done is downright annoying.
>
> So, +1 from me on the overall idea.

Good, that is one committer opinion, an infinite improvement over the
previous status:-)

> The challenge here will almost certainly be in the details.

Yep. I'm fine with "your code is not good and creates problems so it is
rejected". I'm trying to avoid "your code was a loss from the start,
whatever you did, because we do not want such a feature".

> I do like the proposal you have of building out a common set of
> capabilities which are shared between psql and pgbench.

Good.

> The other big challenge here is figuring out how to distinguish between
> SQL which should be sent to the server and something which needs to be
> client-side processed.

The current great idea is to use backslash commands to define existing
variables:

psql> \let i 1 + 2 * 3
psql> SELECT :i ;
psql> \if :i >= 5
psql> ...
psql> \endif

> I've never liked the ':var' approach and it really sucks when you want
> to combine that variable with something else, but it's what we've got
> and therefore has history behind it.

Indeed. I do not think that changing this would make much sense.

> If you can find a way to improve on that without breaking existing code,
> that'd be fantastic. If not, definitely try to minimize the impact.

I was just planning to set existing :-variables with expressions, I have
no great other idea. Mixing languages is always a pain.

Thanks for your feedback.

--
Fabien.