Re: Using DEFAULT as a parameter value with PQexecPrepare() - Mailing list pgsql-general

From Greg Sabino Mullane
Subject Re: Using DEFAULT as a parameter value with PQexecPrepare()
Date
Msg-id 8759d232bf777962a8f09a094b210ac1@biglumber.com
Whole thread Raw
In response to Re: Using DEFAULT as a parameter value with PQexecPrepare()  ("EXT-Rothermel, Peter M" <Peter.M.Rothermel@BOEING.COM>)
List 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@turnstep.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-----



pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: EDB - oracle compatibility (Nested Tables)
Next
From: Jeff Davis
Date:
Subject: Re: PANIC: corrupted item pointer