Thanks, Greg. That's very informative. I really ought to dig into DBI/DBD internals in the near future, probably using postgreSQL as an example.
I use postgreSQL at home sometimes but not currently at work. -Will -----Original Message----- From: Greg Sabino Mullane [mailto:[EMAIL PROTECTED] Sent: Thursday 23 February 2006 20:42 To: dbi-users@perl.org Subject: Re: Calling a PostgreSQL function via DBI -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some minor notes and corrections. First, hopefully the most important thing to learn from this thread is to always use placeholders. It just saves you so much pain and trouble. :) Louis Gonzales asked: > Two, you didn't actually put ( $1, $2, ... ) , Did you? In your code, > that still needs to remain as the question marks. Actually, the $1 form is perfectly acceptable, and even preferable, as it can be easier to read and handles the case of the same placeholder used more than once in a statement in a more efficient manner. You can also ue the ":foo" format which is more flexible still. DBD::Oracle and others handle non-"?" placeholders, although the portability factor is probably not very important when one is dealing with database functions. Christian Stalp asks: > Other question, has anybody experences with PLperl on postgreSQL, thats > looks facinating. And I think my next function will be reallized in PLperl. Yes, Pl/Perl is amazing. All the power of Perl, directly in your database. It is so much easier than fighting with the traditional procedural languages such as pl/sql and pl/pgsql. You can even do things like use DBI from within your PL/Perl functions. Best of all, you can now write your triggers in Pl/Perl. How cool is that? Will Rutherdale said: > In particular, I'm uncomfortable with forms like 1::numeric, etc., where > your code contains assumptions about the data types of your columns. If > you let DBI control it through its knowledge of the schema, then you don't > have to put those assumptions into your code. bind_param() takes care > of that for you, so your code can be more maintainable and portable. Those forms can be very important, as PostgreSQL supports polymorphic functions, so you *must* tell it what data type you are using if you have two or more functions with the same name. If you don't, however, and I am guessing that is the case here, it is usually safe to leave them out. DBI does not "control through its knowledge of the schema" - it is a pure abstraction layer, which has no knowledge of any schema (nor should it). It expects the user to tell it what types through methods such as bind_param. Alternatively, DBD::Pg has the ability (with some caveats) to pass a preparable statement to Postgres and let *it* worry about the quoting when executing. - - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
