PSQL commands: \quit_if, \quit_unless

Hello Corey,

This patch adds two very simple psql commands: \quit_if and \quit_unless.

A few comments about the feature design:

I'm unsure about the name, esp with '_'. There are some \lo_* commands,
but others rely on pasted words (\crosstabview, \errverbose, ...).

I'm wondering if an simplistic interpreted \if \elsif/\else \fi would make
more sense:

Quitting seems a little bit definitive, and means that if I have some
alternatives then I have to have something that relaunch another script
outside...

When \includes are process, does \quit stop the include or the full
script. I'm afraid it is the script.

Now probably an \if... would have also some drawbacks, but ISTM that there
could be less of them.

There is no test provided with the patch.

--
Fabien.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-11-28 20:03 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:

Hello Corey,

This patch adds two very simple psql commands: \quit_if and \quit_unless.

A few comments about the feature design:

I'm unsure about the name, esp with '_'. There are some \lo_* commands,
but others rely on pasted words (\crosstabview, \errverbose, ...).

There are not any other conditional statements - so using "_" can be better

I'm wondering if an simplistic interpreted \if \elsif/\else \fi would make
more sense:

The \if \ese \elseif is not in contradiction with \quit_if - \if is more
generic, \quit_if is simple for implementation, one liner, and best readable

Pavel

On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Corey,

This patch adds two very simple psql commands: \quit_if and \quit_unless.

A few comments about the feature design:

I'm unsure about the name, esp with '_'. There are some \lo_* commands,
but others rely on pasted words (\crosstabview, \errverbose, ...).

I'm completely flexible with regard to the names.

I'm wondering if an simplistic interpreted \if \elsif/\else \fi would make
more sense:

The problem is that \if \elsif \else \fi is anything but simplistic, and
would be a vastly bigger change. Detecting nested if-thens, detecting
un-matched if-thens, etc.

Quitting seems a little bit definitive, and means that if I have some
alternatives then I have to have something that relaunch another script
outside...

When \includes are process, does \quit stop the include or the full
script. I'm afraid it is the script.

It behaves exactly as if the script contained \quit at that location.

Now probably an \if... would have also some drawbacks, but ISTM that there
could be less of them.

It'd be nice, but I'm trying to keep things simple.

There is no test provided with the patch.

Indeed, but testing such a feature is hard within our current test harness.
I welcome suggestions for how to convert the example script in my first
email to tests.

Corey Huinker <corey.huinker@gmail.com> writes:

On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

I'm wondering if an simplistic interpreted \if \elsif/\else \fi would make
more sense:

The problem is that \if \elsif \else \fi is anything but simplistic, and
would be a vastly bigger change. Detecting nested if-thens, detecting
un-matched if-thens, etc.

Yes, but... We've generally refrained from inventing any control flow
metacommands for psql, and TBH this does *not* seem like the place to
start. If we take this patch we are very likely to find that it doesn't
fit in at all whenever someone does show up with a proposal for control
flow features.

If we had an agreed-on sketch for what that feature set would look like,
I wouldn't necessarily object to implementing commands like these first.
But as it stands I think we'd be painting ourselves into a corner.
There's no reason to assume a-priori that this patch creates either naming
conventions or semantics (e.g. what is suitable as a boolean expression)
that we'd be happy with in a larger context.

As far as the original problem goes, I wonder whether what you really
want isn't a \quit command that lets you specify psql's exit code.
I'm not quite seeing how this proposal advances the problem of
communicating between psql and shell portions of a script; but I can
see how returning 0 (ok) vs 1 (error) vs 2 (some special case) would
help with that.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Nov 28, 2016 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Corey Huinker <corey.huinker@gmail.com> writes:

On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO <coelho@cri.ensmp.fr>

wrote:

There's no reason to assume a-priori that this patch creates either naming

conventions or semantics (e.g. what is suitable as a boolean expression)
that we'd be happy with in a larger context.

Would we be happy borrowing the definition of FOUND from pl/pgsql?​

As far as the original problem goes, I wonder whether what you really

want isn't a \quit command that lets you specify psql's exit code.

Actually, I'm seeing this as basically an assertion capability and maybe
should be named as such

\assert_is
\assert_isnot ​

​David J.
​

As far as the original problem goes, I wonder whether what you really

want isn't a \quit command that lets you specify psql's exit code.

The ability to specify an exit code was part of the brainstorming, yes. But
with it was the ability to conditionally quit.

Actually, I'm seeing this as basically an assertion capability and maybe
should be named as such

\assert_is
\assert_isnot ​

That came up too! I see real value in the ability to test for error
conditions. I just had a more immediate need for a non-error exit condition.

On 11/28/2016 04:07 PM, Tom Lane wrote:

... We've generally refrained from inventing any control flow
metacommands for psql

I think it's really time we seriously considered adding some flow
control logic, though. I'm mildly tired of either jumping through hoops
to get around the lack or having to switch to using some other thing
that has the required logic mechanism (hello Perl).

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:

On 11/28/2016 04:07 PM, Tom Lane wrote:

... We've generally refrained from inventing any control flow
metacommands for psql

I think it's really time we seriously considered adding some flow
control logic, though.

Yeah, maybe. I'd be interested to see a fully worked out proposal
for that.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hello,

I think it's really time we seriously considered adding some flow
control logic, though.

Yeah, maybe. I'd be interested to see a fully worked out proposal
for that.

I agree that designing a fuller proposal before including individual parts
would be great and result in a more consistent result.

In order to bootstrap the discussion, I suggest the following:

- boolexpr is a simple "boolean" (t, non 0 int, non empty string.. as
proposed by Corey and Pavel) or !/not boolexp ; it could be extended if
necessary, but I would try to avoid that, as

- actual more complex expressions could be left to the server through SQL
which simplifies the client a lot by avoiding an expression language
altogether

- then having a conditional block is very versatile and can be adapted to
many use cases... maybe all

- \quit CODE, or I would prefer \exit CODE, could be used to exit while
controlling the status

It could look like (although I do not like gset in this context, but
anyway):

SELECT ... AS has_foo_extension \gset
SELECT ... AS has_bla_extension \gset
\if :has_foo_extension
...
\elif :has_bla_extension
...
\else -- no foo nor bla extension
\echo please install foo or bla extension
\exit 1
\fi -- extension
...
SELECT ... AS has_xxx_feature \gset
\if ! :has_xxx_feature
\echo "feature xxx is needed, aborting"
\exit 2
\fi
...

--
Fabien

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-11-29 8:44 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:

Hello,

I think it's really time we seriously considered adding some flow

control logic, though.

Yeah, maybe. I'd be interested to see a fully worked out proposal
for that.

I agree that designing a fuller proposal before including individual parts
would be great and result in a more consistent result.

In order to bootstrap the discussion, I suggest the following:

- boolexpr is a simple "boolean" (t, non 0 int, non empty string.. as
proposed by Corey and Pavel) or !/not boolexp ; it could be extended if
necessary, but I would try to avoid that, as

Now, the psql statements are designed do nothing in syntax error. I am not
sure about be more strict in this case. I see strong advantages - but it
can be little bit different than current behave.

- actual more complex expressions could be left to the server through SQL
which simplifies the client a lot by avoiding an expression language
altogether

- then having a conditional block is very versatile and can be adapted to
many use cases... maybe all

- \quit CODE, or I would prefer \exit CODE, could be used to exit while
controlling the status

It could look like (although I do not like gset in this context, but
anyway):

SELECT ... AS has_foo_extension \gset
SELECT ... AS has_bla_extension \gset
\if :has_foo_extension
...
\elif :has_bla_extension
...
\else -- no foo nor bla extension
\echo please install foo or bla extension
\exit 1
\fi -- extension
...
SELECT ... AS has_xxx_feature \gset
\if ! :has_xxx_feature

I prefer the commands instead symbols - the parsing and processing symbols
should be more complex than it is now. A psql parser is very simple - and
any complex syntax enforces lot of code.

\if_not

Regards

Pavel

Hello Pavel,

Now, the psql statements are designed do nothing in syntax error. I am not
sure about be more strict in this case. I see strong advantages - but it
can be little bit different than current behave.

Indeed, an error on a conditional construct should stop the script, which
is slightly different that "go on whatever", which is okay in the
interactive mode.

I do not see that as an issue, just as features which are more interactive
vs script oriented and behave accordingly: typing a \if in interactive
does not makes much sense, because you have tested something is there, so
you know the answer and can act directly, so there is no point using a
condition.

\if ! :has_xxx_feature

I prefer the commands instead symbols - the parsing and processing
symbols should be more complex than it is now. A psql parser is very
simple - and any complex syntax enforces lot of code. \if_not

My 0,02 €, which is just a personal opinion:

I think that handling manually "!/not" would be worth the effort rather
than having two commands, especially if the boolean expression syntax may
be extended some day and the negative if would become obsolete.

If there is a negative condition syntax, I would slightly prefer \ifnot to
\if_not or worse \unless. I would disaprove strongly of \unless because it
looses the clear symmetry with a closing \fi.

--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

My 0,02 €, which is just a personal opinion:

I think that handling manually "!/not" would be worth the effort rather
than having two commands, especially if the boolean expression syntax may
be extended some day and the negative if would become obsolete.

If there is a negative condition syntax, I would slightly prefer \ifnot to
\if_not or worse \unless. I would disaprove strongly of \unless because it
looses the clear symmetry with a closing \fi.

--
Fabien.

Pavel had previously written this patch
http://ftp.pgpi.org/pub/databases/postgresql/projects/pgFoundry/epsql/epsql/epsql-8.5-develop/psql-enhanced-macros.diff
which I leave here as a point of reference.

Obviously, there's a lot more in there than we'd need, and it's back quite
a few versions.

I agree that the boolean tests available should be *very* simple, and all
of the weight of complex calculation should be put in SQL, like we do with
\gset

I propose those be:

\if STRING : true if STRING evaluates to true via ParseVariableBool, empty
means false
\ifnot STRING: true if STRING evaluates to false via ParseVariableBool,
empty means false
\ifdef psql_var: true if psql_var is defined
\ifndef psql_var: true if psql_var is not defined, helpful for when --set
var=val was omitted and should be defaulted

A full compliment of \elseif \elseifnot \elseifdef \elseifndef, each
matching the corresponding \if* above. I'm ok with these being optional in
the first revision.

\else - technically we could leave this out as well
\endif

Then seems like we need an if-state-stack to handle nesting. At any given
point, the mode could be:

1. None

psql currently isn't in an if-then structure, no non-conditional statements
are skipped. any conditional commands other than \if* are an error.
For that matter, the script can always add a new level to the stack with an
\if* command.

2. If-Then

psql is currently executing statements in an \if* branch that evaluated to
true. valid conditional commands are: \if*, \else* \endif

3. If-Skip

psql is currently in a block that evaluated to false, and will still parse
commands for psql-correctness, but will skip them until it encounters an
\endif or \else*

4. Else-Then

Just like If-Then, but encountering an \else* command would be an error.

5. Else-Skip

Just like If-Skip, but encountering an \else* command would be an error.

The only data structure we'd need is the stack of enums listed above. Any
commands would check against the stack-state before executing, but would
otherwise be parsed and checked as they are now. The new \commands would
manipulate that stack.

Does that seem work-able?

Hello Corey,

I agree that the boolean tests available should be *very* simple, and all
of the weight of complex calculation should be put in SQL, like we do with
\gset

Yes.

I propose those be:

\if STRING : true if STRING evaluates to true via ParseVariableBool, empty
means false

Yep.

\ifnot STRING: true if STRING evaluates to false via ParseVariableBool,
empty means false

I'd like other opinions about having unique \if and an not operator, vs
multiplying \if* and possibly \elif* keywords.

\ifdef psql_var: true if psql_var is defined
\ifndef psql_var: true if psql_var is not defined, helpful for when --set
var=val was omitted and should be defaulted

Hmmm. Would you have an example use case that could not be done simply
with the previous ifs? cpp did that end ended up with a single if in the
end.

A full compliment of \elseif \elseifnot \elseifdef \elseifndef, each
matching the corresponding \if* above. I'm ok with these being optional in
the first revision.

\else - technically we could leave this out as well
\endif

For consistency, the possible sources of inspiration for a syntax with an
explicit end marker are:

- PL/pgSQL: if / then / elsif / else / endif
- cpp: if / elif / else / endif
- sh: if / then / elif / else / fi

Now "then" is useless in a line oriented syntax, for which the closest
example above is cpp, which does not have it. I think that we should stick
to one of these.

I like the shell syntax (without then), but given the line orientation
maybe it would make sense to use the cpp version, close to what you are
proposing.

I cannot remember a language with elseif* variants, and I find them quite
ugly, so from an aethetical point of view I would prefer to avoid that...
On the other hand having an "else if" capability makes sense (eg do
something slightly different for various versions of pg), so that would
suggest to stick to a simpler "if" without variants, if possible.

Then seems like we need an if-state-stack to handle nesting. [...]

Yes, a stack or recursion is needed for implementing nesting.

States: None, If-Then, If-Skip, Else-Then, Else-Skip.

With an "else if" construct you probably need some more states: You have
to know whether you already executed a block in which case a subsequent
condition is ignored, so there is a state "skip all to end" needed.

Does that seem work-able?

Sure. I think the priority is to try to agree about a syntax, the
implementation is a detail.

--
Fabien.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hmmm. Would you have an example use case that could not be done simply
with the previous ifs? cpp did that end ended up with a single if in the
end.

I think this is what you're asking for...

$ cat not_defined.sql
select :'foo';

$ psql postgres --no-psqlrc -f not_defined.sql --set foo=bar
?column?
----------
bar
(1 row)

$ psql postgres --no-psqlrc -f not_defined.sql
psql:not_defined.sql:3: ERROR: syntax error at or near ":"
LINE 1: select :'foo';
^

Now, if we instead added a way for psql to test whether or not a psql var
was defined and set that boolean as ANOTHER variable, then we could avoid
\ifdef and \ifndef.

For consistency, the possible sources of inspiration for a syntax with an
explicit end marker are:

- PL/pgSQL: if / then / elsif / else / endif
- cpp: if / elif / else / endif
- sh: if / then / elif / else / fi

Now "then" is useless in a line oriented syntax, for which the closest
example above is cpp, which does not have it. I think that we should stick
to one of these.

I like the shell syntax (without then), but given the line orientation
maybe it would make sense to use the cpp version, close to what you are
proposing.

I think we should use pl/pgsql as our inspiration, though there's no need
for the "then" because psql commands end the line....which makes it
identical to the C++ version.
But if we can get this thing done, I really don't care which we use.

I cannot remember a language with elseif* variants, and I find them quite
ugly, so from an aethetical point of view I would prefer to avoid that...
On the other hand having an "else if" capability makes sense (eg do
something slightly different for various versions of pg), so that would
suggest to stick to a simpler "if" without variants, if possible.

We need to keep things easy to parse. Earlier someone said no psql command
should ever have more than 2 parameters, and generally only one. Increasing
the number of commands allows us to avoid multi-parameter commands. So it's
a trade-off, we have more, simpler commands, or fewer, more complicated
ones.

\if [not] [defined] [<string>]
\elsif [not] [defined] [<string>]

is problematic if string is ever "not" or "defined". If someone can show me
a way around that, I'm game.

Then seems like we need an if-state-stack to handle nesting. [...]

Yes, a stack or recursion is needed for implementing nesting.

States: None, If-Then, If-Skip, Else-Then, Else-Skip.

With an "else if" construct you probably need some more states: You have
to know whether you already executed a block in which case a subsequent
condition is ignored, so there is a state "skip all to end" needed.

Right, we'd have to check every level of the stack for a skip-state, not a
big deal.

On 11/29/2016 03:07 PM, Fabien COELHO wrote:

I cannot remember a language with elseif* variants, and I find them
quite ugly, so from an aethetical point of view I would prefer to
avoid that... On the other hand having an "else if" capability makes
sense (eg do something slightly different for various versions of pg),
so that would suggest to stick to a simpler "if" without variants, if
possible.

FTR I *strongly* disagree with this. (And if you can't remember a
language that comes with them then you need to get out more. The Bourne
shell, where it's spelled "elif", and Ada are two obvious examples.)

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11/29/16 5:08 PM, Andrew Dunstan wrote:

On 11/29/2016 03:07 PM, Fabien COELHO wrote:

I cannot remember a language with elseif* variants, and I find them
quite ugly, so from an aethetical point of view I would prefer to
avoid that... On the other hand having an "else if" capability makes
sense (eg do something slightly different for various versions of pg),
so that would suggest to stick to a simpler "if" without variants, if
possible.

FTR I *strongly* disagree with this. (And if you can't remember a
language that comes with them then you need to get out more. The Bourne
shell, where it's spelled "elif", and Ada are two obvious examples.)

Not to mention PL/pgSQL and Perl.

--
-David
david@pgmasters.net

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11/29/2016 05:25 PM, David Steele wrote:

On 11/29/16 5:08 PM, Andrew Dunstan wrote:

On 11/29/2016 03:07 PM, Fabien COELHO wrote:

I cannot remember a language with elseif* variants, and I find them
quite ugly, so from an aethetical point of view I would prefer to
avoid that... On the other hand having an "else if" capability makes
sense (eg do something slightly different for various versions of pg),
so that would suggest to stick to a simpler "if" without variants, if
possible.

FTR I *strongly* disagree with this. (And if you can't remember a
language that comes with them then you need to get out more. The Bourne
shell, where it's spelled "elif", and Ada are two obvious examples.)

Not to mention PL/pgSQL and Perl.

Indeed.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Nov 29, 2016 at 01:10:06PM +0100, Fabien COELHO wrote:

If there is a negative condition syntax, I would slightly prefer \ifnot to
\if_not or worse \unless. I would disaprove strongly of \unless because it
looses the clear symmetry with a closing \fi.

I take it \sselnu is right out.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

David Fetter <david@fetter.org> writes:

On Tue, Nov 29, 2016 at 01:10:06PM +0100, Fabien COELHO wrote:

If there is a negative condition syntax, I would slightly prefer \ifnot to
\if_not or worse \unless. I would disaprove strongly of \unless because it
looses the clear symmetry with a closing \fi.

I take it \sselnu is right out.

[ splorf... ] But really, \fi is something that could only be loved
by a certain academic breed of hackers. I'd go for \endif, probably.
That still doesn't relate well with \unless, so +1 for \if, \ifnot,
\else, and \endif.

I'm not really convinced that we need an \elseif at this point.
It could be added later if people find it compelling, but I'm
having a hard time believing that it's essential.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers