| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PSQL commands: \quit_if, \quit_unless |
| Date: | 2016-12-04 16:35:55 |
| Message-ID: | alpine.DEB.2.20.1612041730020.4497@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Pavel,
> Some possibilities from pgbench can have sense in psql too - generating
> some random numbers from a range.
Could you expand on the use case where this would be useful?
> In the end we use one parser for psql and for pgbench.
Note that "master" lexer is already shared, thanks to Tom, so as to detect
consistently where a query ends.
> I agree, so step 2 should be enough, and I accept so there is opened door
> for any future enhancing.
Good, because that was the idea:-)
> We can implement some client side boolean functions (similar to pgbench
> functions that can cover often tasks: version_less, version_greather,
> user_exists, tables_exists, index_exists, variable_exists, schema_exists,
Yes, that is a possibility, but this can already be queried into a
:-variable, so it is less indispensable.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2016-12-04 16:55:11 | Re: PSQL commands: \quit_if, \quit_unless |
| Previous Message | Adrian Klaver | 2016-12-04 15:06:47 | Re: Select works only when connected from login postgres |