in reply to DBD::Pg - $sth->execute($csv_var) ERROR


I wouldn't expect that to work: In order to prepare/compile the SQL statement, PostgreSQL is going to want to know the column names in advance. I'd suggest something a bit more like this:

# Given a list of column names build a placeholder list of the same le +ngth my @columns = ( 'customer_ID', 'reference1', 'foo', ... ); my $placeholders = join(", ", map { '?' } @columns); # Build the SQL statement my $SQL = "INSERT INTO myTable (" . join(", ", @columns) # column names . ") VALUES ($placeholders)"; my $STH = $DBH->prepare_cached($SQL); # Then if you have a reference to an array of values, use it like: my $rValues = [ 'Customer_1', 'ref5', 1, ... ]; $STH->execute(@$rValues); # Or you can hand it an array: my @values = ( 'Customer_2', 'ref99', 3, ... ); $STH->execute(@values); # or even just explicit values: $STH->execute("Customer 5", "ref3", 7, ... );


When your only tool is a hammer, all problems look like your thumb.

Replies are listed 'Best First'.
Re^2: DBD::Pg - $sth->execute($csv_var) ERROR
by perlygapes (Sexton) on Mar 13, 2020 at 01:13 UTC
    Reading through your example, I hear a ticking sound. I think I get what you're saying.
    So...before any looping and generation of values to be INSERTed, I need to give Pg the list of column names when I first send the PREPARE to Pg?
    I just looked at cpan again. It appears that in every example given, the prepare statement already has the column name(s). OK, I will try your suggestion.
Re^2: DBD::Pg - $sth->execute($csv_var) ERROR
by perlygapes (Sexton) on Mar 16, 2020 at 03:53 UTC
    Well, OK.
    Your Pastoral Guidance has borne fruit and blessed my scriptural offerings.
    I see smoke rising from the alter as I turn the STHandle on the door to data salvation.
    But lo, are there wolves among these sheep?
    Have I put my trust in a False Religion?

    I receive no admonitions from Pg, yet upon SELECT supplications, it is as if my offerings are remembered no more. I wonder, are my indulgences counted as nothing more than lip service?

    I accept, of course, the answer to this question may fall outside of the remit of the Perl Priesthood. Perhaps this is a question for the PG Priesthood?

    Can Perl Priests intercede with Pg?
    Doth thou knowest how to solicit exegetical corrective advice from Pg?

    Must I make an open confession of faith with:

    If I say $sth->errstr(); will Pg enlighten me?



      I'd definitely try the commit to see if that does the trick, but I'd also check to see if the statement had an error or not. If it *does*, then you can use the AutoCommit flag on the connect statement to avoid having to do a commit after every operation (though you might prefer the safety of handling commit yourself).

      Since you could be getting an error from Pg, you'll want to check the error status of any command. An insert will fail if you violate a constraint on the table for example. So I tell DBI (on the connect statement) to check every statement and raise errors (using RaiseError and PrintError).


      When your only tool is a hammer, all problems look like your thumb.

        Hmmm...that's excellent exegesis.

        Whence I had thought I besought for errors to be caught then taught, I had:

        my $dbh = DBI->connect($DSN, $userid, $sesame, { AutoCommit => 0, RaiseError => 1, PrintError => 0 }) or die "Connection failed!\n" . $DBI::errstr;

        Hence I shall beseech for errors to be bleached and for Pg to teach me with:

        my $dbh = DBI->connect($DSN, $userid, $sesame, { AutoCommit => 1, RaiseError => 1, PrintError => 1 }) or die "Connection failed!\n" . $DBI::errstr;

        May thy code be blessed by the Profit of thy scripts.