Re: [HACKERS] psql -f inconsistency with "copy from stdin"

The -f option is just another way of saying "get the input from there". If  you use both -f and stdin you're in
essencesaying "get the input from  there and there", and that feature does not exist in psql and would be  hard to
extendto the general case.
 

But there are specifically two kinds of input involved here [*]:

- input of SQL commands and such to psql
- input of data to a COPY command

To me these are conceptually very distinct (in much the same way you
have distinguished already between various output streams; in fact,
I'm not sure how you have matched those with the output stream from
COPY, but it might be relevant to think about that in light of this
discussion).  Thus, to me it makes sense to say "take input from there
and there," as long as it is clear that one "there" refers to one
input stream and the other to the other one.  For example, -f
naturally refers to the first one above, while the STDIN naturally
refers to the second.

Saying that -f should override all other sources of input is
inconsistent in its own way; after all, that doesn't override a COPY
FROM "filename" command, does it?  In that case, you maintain a
distinction between two different input streams.  It seems that
dropping that distinction for the special case of "filename" == STDIN
is introducing unnecessary confusion into the semantics of commands.

In short, I'm not really convinced that it is unreasonable to expect a
command like COPY (or \copy) to be able to associate itself with an
input (or output) stream that is different from that implied by -f,
given that the nature of the various I/O streams is so different and
clearly defined.

Cheers,
Brook

[*] I'm not sure what you mean by the "general case," but I can't
think of any other commands, at least SQL commands, that are naturally
associated with more than one input stream, namely the source of the
command itself which may include embedded data.  Unless I'm missing
something here, I suspect the "general case" is just fine and doesn't
interact with the problem I raised.  What is problematical is the
special case of a command (perhaps there are others?) that inherently
involves more than one input stream: the source of the command itself
and the source of data upon which the command operates.