Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
If we are talking about inserting the function definition into the
query as a subquery and then letting the parser treat it as a
subquery, then I see no reason to use either the existing function or
view subsystems. It sounds more like we are discussing a macro
language.
Which is pretty much what a SQL function is already. I don't see a need
to invent a separate concept. To the extent that macros have different
semantics than functions (eg, multiple evaluation of arguments) the
differences are generally not improvements IMHO ...
regards, tom lane
I have numerous times run EXPLAIN ANALYZE on my queries with SQL functions
embedded and gotten different (far worse) results than if I manually inline the
function following the macro expansion idea above. That has led me to wish that
postgres would inline it for me. That doesn't prove that the macro idea is
needed; it might be that the SQL function systems needs more work. (In fact, I
haven't done this since 8.0.3, so I'm not sure that 8.1 even does a bad job
anymore.)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
