Re: PSQL commands: \quit_if, \quit_unless

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

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.

> 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-12-19 17:35:46 Re: Hash Indexes
Previous Message Peter Eisentraut 2016-12-19 17:25:50 Re: Logical replication existing data copy