From: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Using DEFAULT as a parameter value with PQexecPrepare() |
Date: | 2012-04-06 20:14:29 |
Message-ID: | 8759d232bf777962a8f09a094b210ac1@biglumber.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> I simplified my example somewhat. I usually have six of
> these "optional" parameters. The number of prepared statements
> would be too many for this approach.
> I will follow your advice in the cases where I just one or two
> of the "optional" parameters.
Well, it shouldn't be too bad if you can build them dynamically and
let the app track them, e.g. a hash/LL with the column names smushed
together. A little more work, but worth it if you are calling these
often.
...
> I can at least use PQexecParams() to get some SQL injection
> protection and avoid the escaping and quoting of the parameter values.
One other way I should mention is that if your app knows it, it can always
pass in the default value(s) directly. :)
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201204061612
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAk9/TpQACgkQvJuQZxSWSsjRdwCdEjDz0K54rNlwb+nECXoT1TMB
VvIAn325b3Sjcag0MqaiPtsPpm+Q1/zj
=aZDP
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2012-04-06 21:49:28 | Re: PANIC: corrupted item pointer |
Previous Message | John R Pierce | 2012-04-06 17:42:05 | Re: EDB - oracle compatibility (Nested Tables) |