Re: proposal: multiple psql option -c
От | Tom Lane |
---|---|
Тема | Re: proposal: multiple psql option -c |
Дата | |
Msg-id | 22800.1447788325@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: proposal: multiple psql option -c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: proposal: multiple psql option -c
Re: proposal: multiple psql option -c |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Nov 16, 2015 at 6:05 PM, Andrew Dunstan <andrew@dunslane.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. And backwards compatibility is usually a strong argument around here anyway. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: