SQL escaping

[Alan DeKok]

Phil Mayers wrote:
> I'd like to add a patch that uses the correct escaping function - for
> example, PQescapeStringConn in libpq - when expanding SQL strings. For
> various reason we find the "safe-characters" encoding a bit limiting for
> us.

  Yup.

> It seems like it might be a good idea to use the underlying SQL driver
> escape function if one is present.

  That would be preferable.

> Unfortunately this is a bit more complex than it first looks. In
> particular, the RADIUS_ESCAPE_FUNC prototype only receives the in, out
> and length params - no reference to the request or any other context it
> is called from.

  That should be fixed.

> Does anyone have any insight into how to go about this? In particular, I
> note that the libpq API requires a reference to the connection object
> you're about to send the query down, because per-connection attributes
> (like client encoding) might affect the escaping. This could be doubly
> troublesome if you are talking to >1 backend with distinct SQL settings
> (a bad idea I know).
> 
> Suggestions welcome - is this more trouble than it's worth?

  It's worth it.

  My $0.02 is to do a series of patches.

add REQUEST and context (void*) to the RADIUS_ESCAPE_FUNC.

Add it to the prototypes, to all modules (as UNUSED), and have xlat.c
store the context, and pass it and REQUEST to the calling function

then, add the proper pass of the context in LDAP, SQL, etc.
individually.  Have it pass the right context, and then use it in the
escaping function.

  Of course, this should all be in the 3.0 branch.