Re: PSQL commands: \quit_if, \quit_unless

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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-19 17:41:53
Message-ID: CAFj8pRDBo+CRHgY9gGHEBHMKWM_9+iN=senxpuCQhvy8V9oi8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2016-12-19 18:30 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Sat, Dec 17, 2016 at 3:39 PM, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
> 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
> >> be skipped if the \while condition turns out now to be false.
> >
> > This might be what you meant when you said "those commands back on the
> > stack", but I think we'd have to remember not a list of commands, but the
> > raw string of bytes from the start of the \while to the \endwhile (or
> > equivalent), because any psql vars within that block could themselves be
> a
> > non-parameter part of a command:
> >
> > -- 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 remembering past
> > commands
> > select
> > case
> > when random() < 0.5 then '\ir my_script.sql'
> > when random() < 0.7 'select * from a_table; select count(*) from
> > another_table;'
> > else 'select null as foo;'
> > end as cmd
> > \gset
> > :cmd
> >
> > And even then, things get complicated, because an \ir include which
> makes it
> > this iteration might not make it the next, and the \endwhile might have
> been
> > inside that include, or vice-versa, an included file starts a \while it
> > doesn't finish.
>
> 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
> $INSERT_YOUR_FAVORITE_SCRIPTING_LANGUAGE_HERE, you could do all of
> this stuff very easily without any contortions. I've always thought
> of psql as something that's fine for interactive use and goofy trivial
> scripting but not really suitable for serious work. I grant that you
> seem to be making it serve the purpose, but, man.
>

The integration of any scripting environment with SQL is much more less
than in psql - just some easy scenarios are in psql natural.

It is similar why some people like me, prefer PLpgSQL against Java, Perl,
...

years ago there was a bash integrated with postgres - for me nice idea, but
this project is dead.

>
> > So maybe what we store is a stack of buffers that are currently open
> (STDIN
> > being captured as a buffer only when a \while starts, everything else
> being
> > files), and additionally have a stack of positions where a \while started
> > (buffer_id, position in buffer).
>
> Yeah, sounds about right.
>
> > Additionally, we could assert that all \while-\endwhile pairs must
> happen in
> > the same MainLoop (aka file), and mismatches are an error.
>
> Sounds prudent.
>
> > I'm happy to keep sketching out what control structures might look like
> and
> > how to implement them. But I'm also happy to leave while/for loops out
> for
> > now.
>
> Right, I think that while/for can be left for another time, as long as
> the plan doesn't preclude doing it someday.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2016-12-19 18:03:55 Re: PSQL commands: \quit_if, \quit_unless
Previous Message Robert Haas 2016-12-19 17:35:46 Re: Hash Indexes