I wrote:
> So, unless there's a really good reason why fn_collation should be in
> FmgrInfo and not FunctionCallInfo, I'm going to see about moving it.
It looks like the single largest PITA involved in this change is that
the FunctionCallN/OidFunctionCallN/DirectFunctionCallN families of
functions really ought to take a collation argument, and there are
approximately 540 existing calls of those functions in the source tree.
Of those calls, a pretty substantial majority don't really need
collation info, because they are calling functions that are known not
to care about collations. So while I could go around and add an
"InvalidOid" argument to each one, it seems like an invasive change
for rather small benefit.
What I'm thinking about doing instead is establishing these conventions:
1. The existing names with a "C" appended (eg, OidFunctionCall2C) will
take a collation argument (in particular, this replaces the existing
DirectFunctionCall1WithCollation and DirectFunctionCall2WithCollation,
which seem a bit verbosely named for my tastes).
2. The actual functions in fmgr.c will just be the "C" versions. We'll
preserve source-level compatibility by #define'ing the old names as
macros that expand to call the "C" functions with InvalidOid for the
collation.
This will avoid needing source-code changes except in the places where
collations actually have to be passed.
I don't think this is quite what we would have done if starting in a
green field, but I doubt it's worth the hassle to convert all the
existing calls to add an argument.
Objections, better ideas?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
