These approaches are to some extent orthogonal, ISTM. Maybe the best solution would be to do as Tom suggests and just change psql (and, I would add, pg_dump) to act nicely here, and if other interface users/authors need/want something along these lines re-examine the issue. I use JDBC for my web clients in my current project, but I wouldn't create a function in the client. I probably wouldn't using DBI/DBD:Pg either. So taking myself as a sample of one perhaps it is true that it's only needed in psql :-)
I'm all for minimal solutions as long as they look nice.
cheers
andrew
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Let me jump in --- there is the issue of how to prevent the backend from
running the query through the lexer/parser. The cleanest idea presented
was:
[snip]
That's the same idea that was being discussed in this thread. I was trying to remind people of the existence of prior discussion with different (and IMHO better) ideas.
The interesting thing I missed at first viewing was that there is a
semicolon after the first line. This allows the backend to go into a
COPY-like mode where the client can pass lines to the backend bypassing
the lexer/parser.
What I don't like about this scheme is that it requires mods on both the backend and client sides, to solve a problem that could be solved as well or better (and definitely more simply) on the client side alone. People are being misled by considering only psql, which is so stupid that it might actually not need any change to be used with a COPY-based function definition mode. I doubt that is true of any other client. For a client that actually understands it's doing a function definition, this is *not* simpler nor better. Instead of running a string-literal-quotify transformation on the function text (which you must admit is trivial), the client has to support switching into the COPY protocol. That's not simpler. Add in any meaningful error recovery (what do you do if the backend doesn't switch into COPY mode?) and it's substantially more complex.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
