On 11/06/11 1:52 PM, NTPT wrote:
> I think that features are proposed because user(s) want it, need
> it, because it can be useful for other peoples too, because with this
> can people solve their problems and/or improve performance and
> security of their applications. Not because someone else have
> something similar...
well, the functionality you describe could be implemented externally to
postgres in as a binding layer, at least for a specific programming
environment, such as Perl DBI, Java JDBC, python, etc etc. most of
these bindings already have the idea of prepared statements, so adding
an API to fetch a named statement from a table of such shouldn't be that
difficult. Implementing it this way would be a good way to demonstrate
its utility, iron out design issues, and so forth. If in fact it
proved to be of general interest, it could then be re-implemented as a
contributed project, or perhaps in the postgres core.
generally, built in functionality in PostgreSQL closely follows existing
SQL database standards and practices, I've not seen or heard of any such
'persistent named prepared statements' before in any database system, so
I suspect the core developers aren't going to go anywhere with this
suggestion, but of course, I can't speak for them.
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
