Re: Desirability of client-side expressions in psql?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Desirability of client-side expressions in psql?
Date: 2018-07-07 14:31:03
Message-ID: 20180707143103.GO27724@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greeting Fabien,

* Fabien COELHO (coelho(at)cri(dot)ensmp(dot)fr) wrote:
> >I set it to Rejected. This seems like a misuse of the CF process,
> >which is about discussing actual patches.
>
> Somehow.

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".

> 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. The challenge here will almost
certainly be in the details. I do like the proposal you have of
building out a common set of capabilities which are shared between psql
and pgbench.

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. 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. 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.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-07-07 15:11:24 Re: peripatus build failures....
Previous Message Thomas Munro 2018-07-07 13:11:11 Re: setproctitle_fast()