On 18/06/13 13:02, Arran Cudbard-Bell wrote:
We discussed that, and it seems like it could be done if we added callbacks for xlat parsing during xlat registration. Then all the pre-prepared statements could be created during startup.
The key unknowns with this, is whether a connection is required to the server in order to create the bound statements, and whether it's ok to share them between multiple handles.
If I understand what you mean here - things like PREPARE - those sort of server-side statement/param solutions have caveats on some databases. I would not recommend them for this use-case, certainly not in postgres. And yes, in postgres they are per-connection and cannot be shared. [As an example - PREPAREd statements in postgres have different query planning behaviour than "long form" SQL queries, so their performance can vary over the lifetime of the connection even for the same parameters. Even worse, older versions of postgres might always use a generic query plan for PREPAREd statements.] In general, PREPARE is a niche solution. If you want missing attributes to expand to the unquoted null keyword, then I think you'll have to drill down into the xlat to determine whether the attribute is absent or empty. Personally I don't think even that would be desirable - it means string expansions in SQL will work different to the rest of the server. I'd just leave it at "use NULLIF".
As far as I'm concerned, the *only* thing FreeRADIUS needs to do is properly quote the variables it expands into a SQL query, which it already does.
OK. Then the default substitution should probably only be done for certain modules where it is an issue.
I think that would be confusing.
On the command line blank arguments do affect programs which use positional arguments as multiple chars of whitespace are condensed.
You've lost me. On the command line, that's done by the shell, and if people using shell want to preserve whitespace, they must quote appropriately. Conversely FreeRADIUS splits into argv[] before doing xlat, so the actual value of an attribute - whitespace and all - is passed to the execv call. I consider this a good thing - this shell command: /tmp/script -a foo -b '' -c ' bar ' ...is perfectly legal, and not even that uncommon.