Thank you for any help you are able to give.
Justin.
--
Justin C, by the sea.
Hi
Fortunately, there is only one sane answer:
DBI as the interface module
and DBD::Pg as the driver (there are drivers for most databases which makes
it such a dream).
HTH
Tim
http://dbi.perl.org
http://search.cpan.org/~timb/DBI-1.56/DBI.pm
http://search.cpan.org/~dbdpg/DBD-Pg-1.49/Pg.pm
> Searching CPAN for PostgreSQL returns a large list
> of modules, I've been through a lot of pages and nothing stands out as
> being the/a module that I need. Is there a good reference anywhere, in
> simple terms (I've no experience *at all* with databases - but I do have
> a book!),
Wait, what? You have no experience with databases, but you're trying
to write a script to do database interactivity? You are putting the
cart before the horse. You need to learn about Databases and SQL
before you attempt to do any programming using that database. I
suggest you find a group that will point you towards resources for
learning about these topics, and then once you're comfortable using a
database natively, come back here and read those sites above to learn
how to use that database in a Perl script.
Paul Lalli
Thank you Paul, and Tim. I've already got the DBI bit (I kinda guessed
I'd need it). The DBD::Pg is what I'm missing.
> I've a PostgreSQL database that I need to interact with using perl. I
> need to be able to add records and amend records only. I'm trying to
> find where to start. Searching CPAN for PostgreSQL returns a large list
> of modules, I've been through a lot of pages and nothing stands out as
> being the/a module that I need. Is there a good reference anywhere, in
> simple terms (I've no experience *at all* with databases - but I do have
> a book!), that'll tell me which module(s) I need?
Oh, for the "howto":
perldoc DBI
and look at the SYNOPSIS.
I think you mostly need:
$rv = $dbh->do($statement, \%attr, @bind_values);
(or perhaps prepare and execute, but do() will do for starters).
Hint - use bindvars, it will save infinite grief with quoting
perldoc DBD::Pg will give you the magic for setting up a Postgresql DSN.
Another hint: setting RaiseError is a good idea - anything goes wrong and it
will blow up your code, even without explicit error checks, which is
usually a GOOD THING (TM) unless you really want to handle failures nicely.
HTH
Tim
You've already gotten the Perl-relevant parts of your answer; I'll just
add that restricting access to add or update is a function of the db, so
you should read the PostgreSQL documention at their website for these
tasks.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
[snip]
Thanks, noted.
Consider DBIx::Simple
http://search.cpan.org/perldoc?DBIx::Simple
--
Affijn, Ruud
"Gewoon is een tijger."
> Justin C wrote:
>
>> I've a PostgreSQL database that I need to interact with using perl. I
>> need to be able to add records and amend records only. I'm trying to
>> find where to start. Searching CPAN for PostgreSQL returns a large list
>> of modules
>
> Fortunately, there is only one sane answer:
>
> DBI as the interface module
>
> and DBD::Pg as the driver
I suspect that virtually all of the other modules found are high-level
tools that build atop those two, and happen to mention in their docs that
they've been "tested against MySQL and PostgreSQL" or some such.
Maybe CPAN should take dependencies into account when sorting its search
results, sort of like how Google takes links into account. That way, for
situations such as this one where you have a very popular base module that
many others use, the base module would be listed first.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
I have to say, that does look much more simple. And, being a complete database dunce, this could be easier for achieving what I want.
I'll compare the documentation tomorrow at work. Thank you.
> Tim Southerwood <t...@dionic.net> writes:
>
>> Justin C wrote:
>>
>>> I've a PostgreSQL database that I need to interact with using perl. I
>>> need to be able to add records and amend records only. I'm trying to
>>> find where to start. Searching CPAN for PostgreSQL returns a large list
>>> of modules
>>
>> Fortunately, there is only one sane answer:
>>
>> DBI as the interface module
>>
>> and DBD::Pg as the driver
>
> I suspect that virtually all of the other modules found are high-level
> tools that build atop those two, and happen to mention in their docs that
> they've been "tested against MySQL and PostgreSQL" or some such.
Must admit I've never really considered anything else. DBI gives me the
control I want with as much or as little complexity as I wish. IMHO, DBI is
probably one of the most complete and professionally written modules in the
whole of CPAN. It meshes with RDBMS's in a way which is natural.
I have noticed the odd attempt to OO-ify DB access, but I've not really seen
the point (and I like OO sometimes).
Just my 2p's worth :)
Cheers
Tim
> I have noticed the odd attempt to OO-ify DB access, but I've not really
> seen the point (and I like OO sometimes).
That sounded stoopid in retrospect - DBI could be argued to have OO like
calling semantics - though I tend to think of it as a "handle" not an
object, hence I don't really think of it as an OO module in the purist
sense, but that's debateable.
I was referring to some Class:: modules, and whilst not wanting to offend
the authors of these other probably very worthy modules, well, for me, I
find all I need in DBI and have never thought it needed anything layered or
added.
I'll go to bed now :)
Cheers
Tim
> I have noticed the odd attempt to OO-ify DB access, but I've not really seen
> the point (and I like OO sometimes).
I think it depends on where your focus is.
If you're focused on the database query and know SQL well, then an additional
OO layer on top of that can be a hindrance.
On the other hand, if your focus is on other parts of the application, and all
you want from the database is an object persistence layer, then the OO layers
are a big help.
Of course, the focus can and does vary from script to script, so there's room
for both approaches.