Our development group needs to have the option of logging all SQL
statements including substituted parameter values. Getting output in the
form:
... WHERE contact.login_con = $1 AND company.login_co = $2
was no problem, but nothing that I tried turning on in the config file
yielded values for $1 and $2.
Digging into the source for 8.1.1 brought me to this code in
.../backend/tcop/postgres.c (lines 1449+)
/* We need to output the parameter values someday */
if (log_statement == LOGSTMT_ALL)
ereport(LOG,
(errmsg("statement: %s", portal_name)));
/*
* Fetch parameters, if any, and store in the portal's memory context.
*/
if (numParams > 0)
It seems to me that a point near the bottom of the loop over parameters
(1564+)
params[i].kind = PARAM_NUM;
params[i].id = i + 1;
params[i].ptype = ptype;
params[i].isnull = isNull;
i++;
}
(params[i].value is set in a couple of places higher up in the loop)
would be a good place to log each parameter, but...
Has this not been done simply because nobody has gotten around to it, or
are there pitfalls? Although I've been using PostgreSQL for several years,
this is my first venture into its source code beyond watching it build.
Also, the Datum params[i].value, does it necessarily hold displayable
text, even when its content is the output of a binary input converter?
Is there a utility log routine somewhere that I can simply feed a
Datum to?
--
Ted Powell <[EMAIL PROTECTED]> http://psg.com/~ted/
GPL code ... It's the difference between
owning your own home and just renting. --PJ
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
