Woops. Bad math on my side, you look correct. I'll submit it to Ed Mergl
later on.
(I'm to blame for this piece of code).
-alex
On Tue, 25 Dec 2001, KAWAI,Takanori wrote:
I've found that DBD::Pg not works with binary data.
It occurs Unterminated quoted string with long invisible-character.
on Linux handles more connections per second than MSSQL on Winblows)
*** REPLY SEPARATOR ***
On 11/12/01 at 8:21 PM Alex Pilosov wrote:
I think you are doing something wrong. DBD::Pg is fast-to-unnoticeable.
I bet that with PHP you do your operations within one transaction
I think you are doing something wrong. DBD::Pg is fast-to-unnoticeable.
I bet that with PHP you do your operations within one transaction (do an
explicit BEGIN or whatever way in PHP you start a transaction), whereas in
perl, you don't do $dbh-{AutoCommit}=0;
The best way to kill postgres'
Why are you using func()?
You should be using dbd-table_attributes(tablename)
But actually, yes, DEFAULT is not being set by DBD::Pg.
If you want to fix it, please edit table_attributes function in Pg.pm in
DBD::Pg source.
-alex
On 9 Nov 2001, Brad Hilton wrote:
Hello,
I am new to using
First thing that comes to mind:
a) do you have an index on tqosinsp_rwd?
b) did you vacuum the table in question?
6000 transactions per hour seems awfully slow.
It would also help if you provide structure of the tables. Version of
postgres, too. If there are awfully large rows, performance will
Yes there is. According to Date (tm) (and to SQL92), =NULL should always
return false. Certain databases (cough access cough) allow that and
translate =null to 'is null', however, the standards say it should not be
done.
You may experience severe lossage if you rely on it, as some databases
Yes, and it rocks my socks. :)
-alex
On Fri, 12 Oct 2001, Mark Riehl wrote:
All - Just curious if anyone is successfully using DBI with PostgreSQL under
Linux? I don't see a lot of traffic about it and may need to use it in the
near future.
Thanks,
Mark
--
Mark Riehl
Agile
On Wed, 10 Oct 2001, Jeff Zucker wrote:
Steve Howard wrote:
The Standard SQL syntax for updating based on a join is this
UPDATE Table1
Set Column1 = r.Column1, Column2 = r.Column2
FROM Table1 l INNER JOIN Table2 r ON l.Column3 = r.Column3
In which standard is
On Wed, 10 Oct 2001, Jeff Zucker wrote:
Alex Pilosov wrote:
On Wed, 10 Oct 2001, Jeff Zucker wrote:
Steve Howard wrote:
The Standard SQL syntax for updating based on a join is this
UPDATE Table1
Set Column1 = r.Column1, Column2 = r.Column2
FROM
Result here: (I put iteration number in output)
55361
55362
55363
55364
55365
Out of memory!
Out of memory!
Callback called exit.
Out of memory!
I'm using a bit old copy of DBD::Pg, but I don't think it makes a
difference. Please check that you have ample memory, and no ulimit in
effect when
You must use bytea type on postgres side to insert binary data, and bind
your variable as SQL_BINARY.
ALternatively, byte64 or hex encode your binary data.
On Wed, 3 Oct 2001, K Old wrote:
Hello,
I am trying to load encrypted data (a credit card number encrypted by the
Crypt::Twofish
On Sat, 1 Sep 2001, Alex Krohn wrote:
my $dbh = DBI-connect(DBI:Pg:dbname=test, postgres, );
my $val = $dbh-quote(q!\'?:!);
print val: $val\n;
my $sth = $dbh-prepare(INSERT INTO foo (a) values ($val));
Placeholders isn't really an option in my case.
I
Quote function is not supposed to quote ? character.
You must do as follows:
my $dbh = DBI-connect(DBI:Pg:dbname=test, postgres, );
my $val = q!\'?:!
my $sth = $dbh-prepare(INSERT INTO foo (a) values (?));
$sth-execute($val);
(And no explicit calls to quote
On Thu, 30 Aug 2001, Jeff Boes wrote:
Perhaps related, perhaps not: what is the purpose of the 'tty=' option in
the driver? I looked at that with an increasingly puzzled expression on my
face (8-), in hopes that I could use that to capture the output.
Not exactly. This is TTY that backend
Your problem is your database structure. Instead of putting things into
500 tables, you should merge them into 1 table.
This is not a perl question, its a database design question.
-alex
On Mon, 13 Aug 2001, Evan Zane Macosko wrote:
Hi everyone,
I am use Perl:DBI to interface to a
a) check if you have nulls in the data. If you do, you must use type
'bytea' and SQL_BINARY to bind to it.
b) Postgres prior to 7.0 had a limit of 4096 bytes per tuple. Tuple header
takes around 50 bytes, so if you had any other fields, you'd be screwed.
Upgrade to latest.
On Thu, 12 Jul 2001,
On Wed, 11 Jul 2001, Wim De Hul wrote:
I'm trying to install DBI 1.18 on a Sparc Solaris 8 server but I still
get the following error:
snip
/usr/perl5/5.00503/ExtUtils/xsubpp -typemap
/usr/perl5/5.00503/ExtUtils/typemap Perl.xs xstmp.c mv xstmp.c Perl.c
cc -c -xO3 -xdepend
I'm one to blame for the bytea support, so :)
Something is mangling chr(128) somewhere. If you do this one with
DBI_TRACE=2, you'll see: INSERT INTO test VALUES ('\\3777600')
I'm looking what's causing it...
---cut---
I'm getting core dumps when I try to use a BYTEA value with
a byte
);
---
dest+=snprintf(dest, strlen(imp_sth-statement)
+ max_len + (statement - dest), %03o, *((unsigned char *)val));
On Wed, 27 Jun 2001, Alex Pilosov wrote:
I'm one to blame for the bytea support, so :)
Something is mangling chr(128) somewhere. If you do this one
19 matches
Mail list logo
