>
>
> As I understood it, the negative feeback was really about sh inspiration
> "if/fi", not about elif/elsif/elseif. I do not think that there was an
> expressed consensus about the later.
>
True
> The closest case is CPP with its line-oriented #-prefix syntax, and I
> still think that we
1: unrecognized value "whatever" for "\if"; assuming "on"
I do not think that the script should continue with such an assumption.
I agree, and this means we can't use ParseVariableBool() as-is. I
already broke out argument reading to it's own function, knowing that
it'd be the stub for
Hello,
I'm personally indifferent to elif vs elsif vs elseif, but I think elseif
was the consensus. It's easy enough to change.
Went with elsif to follow pl/pgsql. In reviewing the original thread it
seemed that "elif" was linked to "fi" and that got some negative feedback.
As I understood
On Mon, Jan 23, 2017 at 4:12 PM, Corey Huinker
wrote:
> I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL
>> has "ELSIF" like perl, that I do not like much, though. Given the syntax
>> and behavioral proximity with cpp, I suggest that "elif" would
>
> I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL
> has "ELSIF" like perl, that I do not like much, though. Given the syntax
> and behavioral proximity with cpp, I suggest that "elif" would be a better
> choice.
>
I'm personally indifferent to elif vs elsif vs elseif,
A few comments:
Argh, better with the attachements:-(
--
Fabien.
if-error-1.sql
Description: application/sql
if-error-2.sql
Description: application/sql
if-error-3.sql
Description: application/sql
if-error-4.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list
And here's the patch. I've changed the subject line and will be submitting
a new entry to the commitfest.
A few comments:
Patch applies, make check is ok, but currently really too partial.
I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL
has "ELSIF" like perl, that
>
>
> Fabien is pressed for time, so I've been speaking with him out-of-thread
> about how I should go about implementing it.
>
> The v1 patch will be \if , \elseif , \else, \endif, where
> will be naively evaluated via ParseVariableBool().
>
> \ifs and \endifs must be in the same "file" (each
On Wed, Jan 18, 2017 at 12:08 AM, Michael Paquier wrote:
> On Wed, Jan 18, 2017 at 3:24 AM, Robert Haas
> wrote:
> > On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote:
> >>
> >> $ cat loop.sql
> >> \if :x < 1000
> >> \echo
On Wed, Jan 18, 2017 at 3:24 AM, Robert Haas wrote:
> On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote:
>>
>> $ cat loop.sql
>> \if :x < 1000
>> \echo :x
>> \set x :x + 1
>> \include loop.sql
>> \fi
>> $ psql --set x=0 -f loop.sql
>>
>> Somebody
On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote:
>
> $ cat loop.sql
> \if :x < 1000
> \echo :x
> \set x :x + 1
> \include loop.sql
> \fi
> $ psql --set x=0 -f loop.sql
>
> Somebody is going to think of that workaround for not having loops, and
> then whine about how
On 1/13/17 11:22 PM, Tom Lane wrote:
I wonder what depth of include-file nesting
psql can support, or whether we'll be able to fix it to optimize tail
recursion of an include file. Because somebody will be asking for that
if this is the toolset you give them.
I think the solution to that is
$ cat loop.sql
\if :x < 1000
\echo :x
\set x :x + 1
\include loop.sql
\fi
$ psql --set x=0 -f loop.sql
Nice one! CPP does not have arithmetic, so it is harder to do that because
one must reimplement arithmetic with #if...
Somebody is going to think of that workaround for not having
Pavel Stehule writes:
> 2017-01-14 0:20 GMT+01:00 Corey Huinker :
>> - leaving loops out for now?
> +1
I'm just going to say one thing about that: some people will remember
that you can build a Turing machine with either conditionals+iteration
Hi
2017-01-14 0:20 GMT+01:00 Corey Huinker :
> Ok, so activity on this thread has died down. I'm not sure if that's
> consensus or exhaustion.
>
the original idea \quit_if is leaved? It is pity - it is common use case -
and because we cannot to implement macros in psql,
Ok, so activity on this thread has died down. I'm not sure if that's
consensus or exhaustion.
Are we good with:
- implementing basic \if EXPR \elseif EXPR \else \endif, where the EXPR is
an expression but is currently limited to a simple string that will be
evaluated for truth via
On Mon, Dec 19, 2016 at 11:23 AM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
>
> > Being able to do more conditional work in psql would make setting up more
> > robust scripts easier and without either losing transaction capabilities
> or
> > session pooling for
David G. Johnston wrote:
> Being able to do more conditional work in psql would make setting up more
> robust scripts easier and without either losing transaction capabilities or
> session pooling for improved performance when large numbers of small
> commands are run in between flow control in
>
> >
> > -- this is how I fake an 'exit 0' now:
> > \set work_needs_to_be_done t
> > select
> > case
> > when :'work_needs_to_be_done'::boolean then ''
> > else '\q'
> > end as cmd
> > \gset
> > :cmd
> >
> > -- ridiculous example to illustrate complications in
On Mon, Dec 19, 2016 at 10:30 AM, Robert Haas wrote:
>
> I see your point. Just out of curiosity, why in the world don't you
> use something other than psql for scripting? I mean, if you accessed
> the data from Perl or Python or
>
2016-12-19 18:30 GMT+01:00 Robert Haas :
> On Sat, Dec 17, 2016 at 3:39 PM, Corey Huinker
> wrote:
> >> To implement \while, we'd also need to remember previous commands so
> >> that when we reach the end of the loop, we can rewind and put all of
>
On Sat, Dec 17, 2016 at 3:39 PM, Corey Huinker wrote:
>> To implement \while, we'd also need to remember previous commands so
>> that when we reach the end of the loop, we can rewind and put all of
>> those commands back on the stack to be executed again, or perhaps to
>>
>
> > (Or in other words, let's see \while ... \endloop in the minimal proposal
> > as well, or at least a sketch of how to get there.)
>
> It seems to me that we could implement \if ... \else ...\endif by
> having some kind of stack that indicates which constructs we're inside
> of and whether
On Fri, Dec 16, 2016 at 12:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I think it would be reasonable for somebody to implement \if,
>> \elseif, \endif first, with the argument having to be, precisely, a
>> single variable and nothing else (not
2016-12-17 16:26 GMT+01:00 Fabien COELHO :
>
> Hello Tom,
>
> So I think it would be reasonable for somebody to implement \if,
>>> \elseif, \endif first, with the argument having to be, precisely, a
>>> single variable and nothing else (not even a negator). [...]
>>>
>>
>
Hello Tom,
So I think it would be reasonable for somebody to implement \if,
\elseif, \endif first, with the argument having to be, precisely, a
single variable and nothing else (not even a negator). [...]
This seems like a reasonable implementation plan to me, not least because
it tackles
2016-12-16 21:18 GMT+01:00 Robert Haas :
> On Fri, Dec 16, 2016 at 12:28 PM, Pavel Stehule
> wrote:
> > why do you need special operator for negation? there is only one use
> case.
> > It can be solved by \if_not
>
> That's exactly the kind of
On Fri, Dec 16, 2016 at 12:28 PM, Pavel Stehule wrote:
> why do you need special operator for negation? there is only one use case.
> It can be solved by \if_not
That's exactly the kind of thing I *don't* want to do. If you
absolutely must have that and you can't wait
2016-12-16 18:33 GMT+01:00 David G. Johnston :
> On Fri, Dec 16, 2016 at 10:28 AM, Pavel Stehule
> wrote:
>
>> 2016-12-16 18:21 GMT+01:00 David G. Johnston
>> :
>>
>>> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas
Robert Haas writes:
> So I think it would be reasonable for somebody to implement \if,
> \elseif, \endif first, with the argument having to be, precisely, a
> single variable and nothing else (not even a negator). Then a future
> patch could allow an expression there
On Fri, Dec 16, 2016 at 10:28 AM, Pavel Stehule
wrote:
> 2016-12-16 18:21 GMT+01:00 David G. Johnston :
>
>> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas
>> wrote:
>>
>>>
>>> If the expected committed patch set includes
2016-12-16 18:21 GMT+01:00 David G. Johnston :
> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas
> wrote:
>
>> On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas
>> wrote:
>> >> - possible incremental implemention steps on this
On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas wrote:
> On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas
> wrote:
> >> - possible incremental implemention steps on this path:
> >>
> >> (1) minimal condition and expression, compatible with
> >> a
On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas wrote:
>> - possible incremental implemention steps on this path:
>>
>> (1) minimal condition and expression, compatible with
>> a possible future full-blown expression syntax
>>
>> \if :variable
>> \if not
But if it does make sense to share, then that's another reason for not
designing something ad-hoc for psql: integrating it later will be more
work in total.
Yes, but not much: evaluating "[!] :var" special syntax would be dropped,
but I do not think that it is the main issue with these
On Tue, Dec 6, 2016 at 8:45 AM, Fabien COELHO wrote:
> There are some differences: pgbench already had one operator at a time
> expressions, while psql has survived till today with none, which suggest a
> less pressing need.
I don't really think so. People have been wanting
Hello Robert,
Your experience as an seasoned core developer and a committer is
probably different:-)
Well, everybody can have their own opinion on what is reasonable.
Sure.
There are times I argue for making a patch smaller (frequent) and
times when I argue for making it bigger (rare).
On Tue, Dec 6, 2016 at 1:28 AM, Fabien COELHO wrote:
> First, my experience as a basic patch submitter is that any patch which does
> more than one thing at a time, even somehow closely related changes, is
> asked to be split into distinct sub-patches, and is harder to get
Hello Robert,
Given the experience with pgbench and the psql context, I do not think that
it would really need to go beyond step 2 above, but I agree that I may be
wrong and it is best to be prepared for that from the start. Given the
complexity and effort involved with (5), it seems wise to
On Sat, Dec 3, 2016 at 2:16 AM, Fabien COELHO wrote:
>> My guess is that something comparable to where pgbench is would be a
>> reasonable target --- not least because I think we should strive to
>> reduce unnecessary differences between psql and pgbench metalanguages.
>>
>>
2016-12-04 20:55 GMT+01:00 Fabien COELHO :
>
> Yes, that is a possibility, but this can already be queried into a
>>> :-variable, so it is less indispensable.
>>>
>>
>> can you show some examples, please?
>>
>
> SELECT COUNT(*) AS has_unit_extension
>FROM pg_extension
Yes, that is a possibility, but this can already be queried into a
:-variable, so it is less indispensable.
can you show some examples, please?
SELECT COUNT(*) AS has_unit_extension
FROM pg_extension WHERE extname='unit' \gset
\echo :has_unit_extension
1
So that
\if !
2016-12-04 17:35 GMT+01:00 Fabien COELHO :
>
> 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?
>
writing test cases
>
> In the
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
2016-12-03 8:16 GMT+01:00 Fabien COELHO :
>
> Hello,
>
> My guess is that something comparable to where pgbench is would be a
>> reasonable target --- not least because I think we should strive to
>> reduce unnecessary differences between psql and pgbench metalanguages.
>>
>>
Hello,
My guess is that something comparable to where pgbench is would be a
reasonable target --- not least because I think we should strive to
reduce unnecessary differences between psql and pgbench metalanguages.
I'm not sure that I'm ready to propose that they should share the same
On 12/2/16 9:24 AM, Robert Haas wrote:
On Fri, Dec 2, 2016 at 11:12 AM, Corey Huinker wrote:
In order for me to understand how high the bar has been set, can you
(Robert/Tom mostly, but I welcome any responses) explain what you mean by
"full-blown expression language"?
On Fri, Dec 2, 2016 at 11:12 AM, Corey Huinker wrote:
> In order for me to understand how high the bar has been set, can you
> (Robert/Tom mostly, but I welcome any responses) explain what you mean by
> "full-blown expression language"? What constructs must it include,
Corey Huinker writes:
> In order for me to understand how high the bar has been set, can you
> (Robert/Tom mostly, but I welcome any responses) explain what you mean by
> "full-blown expression language"? What constructs must it include, etc?
My guess is that something
>
>
> The other problem with not thinking about that general case is that
> people will keep on proposing little bitty features that nibble at
> the problem but may or may not be compatible with a general solution.
> To the extent that such patches get accepted, we'll be forced into
> either
Robert Haas writes:
> Given the precedent in pgbench (cf.
> 878fdcb843e087cc1cdeadc987d6ef55202ddd04), I think it requires an
> amazing level of optimism to suppose we won't eventually end up with a
> full-blown expression language here. I would suggest designing one
>
On Tue, Nov 29, 2016 at 4:43 AM, Pavel Stehule wrote:
> 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
Given the
On 11/30/2016 03:47 AM, Fabien COELHO wrote:
Hello Andrew,
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
Hello Andrew,
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
Hello Tom,
But really, \fi is something that could only be loved by a certain
academic breed of hackers.
Ah ah:-) I'll take that as a compliment:-)
I'd go for \endif, probably. That still doesn't relate well with
\unless, so +1 for \if, \ifnot, \else, and \endif.
Ok, that is a clear
David Fetter 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
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.
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
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"
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
>
>
> 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
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.
>
> 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
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
2016-11-29 8:44 GMT+01:00 Fabien COELHO :
>
> 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
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
Andrew Dunstan 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
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
>
>
> 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
On Mon, Nov 28, 2016 at 2:07 PM, Tom Lane wrote:
> Corey Huinker writes:
> > On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO
> wrote:
>
There's no reason to assume a-priori that this patch creates either naming
> conventions or
Corey Huinker writes:
> On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO 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
>
On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO 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,
>
2016-11-28 20:03 GMT+01:00 Fabien COELHO :
>
> 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
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
This patch adds two very simple psql commands: \quit_if and \quit_unless.
Each takes an optional string parameter and evaluates it for truthiness via
ParseVariableBool().
If a true-ish value is passed to \quit_if, psql will behave as if the user
had input \quit.
\quit_unless will do nothing if
101 - 175 of 175 matches
Mail list logo