Re: proposal: multiple psql option -c

2015-11-17 21:00 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Tue, Nov 17, 2015 at 2:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Mon, Nov 16, 2015 at 6:05 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
> >>> I honestly don't see what's so confusing about it, and if there is any
> >>> confusion then surely we could make sure what's happening is well
> >>> documented.
> >
> >> +1. I'm actually kind of wondering if we should just back up and
> >> change the way -c works instead, and allow it to be specified more
> >> than once. The current behavior is essentially a crock that has only
> >> backward compatibility to recommend it, and not having two
> >> confusingly-similar options is of some non-trivial value.
> >
> > Well, it's not *entirely* true that it has only backwards compatibility
> > to recommend it: without -c in its current form, there would be no way
> > to test multiple-commands-in-one-PQexec cases without hacking up some
> > custom test infrastructure. That's not a very strong reason maybe, but
> > it's a reason.
>
> True. We could have a --no-split-commands option for that case, perhaps.
>
> > And backwards compatibility is usually a strong argument
> > around here anyway.
>
> Yeah, but not - at least in my book - at the expense of being stuck
> with a confusing interface forever.
>
> > I've not been following this thread in any detail, but have we considered
> > the approach of allowing multiple -c and saying that each -c is a
> separate
> > PQexec (or backslash command)? So the semantics of one -c wouldn't
> change,
> > but commands submitted through multiple -c switches would behave
> > relatively unsurprisingly, and we wouldn't need two kinds of switch.
> >
> > Another issue here is how -1 ought to interact with multiple -c.
>
> On a code level, I think the issue here is that ACT_SINGLE_QUERY
> bypasses a lot of stuff that happens in the ACT_FILE case: directly in
> main, there's process_psqlrc(); inside process_file(), there's the
> single_txn handling; then inside MainLoop, there's splitting of
> commands and cancel handling and various other stuff. In my
> imagination, it's like this because originally psql wasn't nearly as
> complicated as it is now, and as features got added in various places,
> -c gradually diverged. I don't know whether that's really what
> happened, but it seems to me that it would be good to bring those
> things back together.
>
> A few years ago there was a proposal to not only allow multiple -c
> options, but to allow -c and -f to be intermingled. This seems really
> rather useful; I'd like to be able to type psql -c do_this_first -f
> script.sql and have that work. But of course it's kind of hard to
> figure out how that should behave given the various differences
> between -c and -f. I think in the long run we'll be better off
> rationalizing the interface; I really doubt how many people, even on
> this mailing list, can even enumerate all the differences between -c
> and -f. If it's too complicated for hackers to remember, it's
> probably not very good for users either.
>

This shouldn't be hard. With proposed patch, you can do "-C '\i xxx' -C '\i
yyyy'" - that is effectively same like multiple -f

and this mix can be really useful }in any order).

Regards

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>