Re: DBD::Pg up for sale
Elizabeth Mattijsen wrote: Also, I can probably ask advice from fellow Amterdam.pm member and DBD::Unify veteran H.Merijn Brand, and my soon-to-be colleague Jos Boumans also implied that he could offer some assistance. My regular contact Email address is [EMAIL PROTECTED] What I know of DBD drivers, I too think it would be madness for someone to have to maintain these without a thorough knowledge of Perl _and_ DBI. Probably well intended madness, but still madness. OK, so I am mad. Now, with that out of the way, why does there have to be one maintainer? We don't have one PostgreSQL server maintainer, and it seems crazy to push all changes to DBD:pg through a single person. At PostgreSQL, we have a collaborative effort, where people post patches, others comment, and when a consensus is reached, the patch is applied. I plan to do very little with DBD-pg except to make sure things are running smoothly within the group of DBD-pg developers, and I will see they get any PostgreSQL information they need. I think David Wheeler has already outlined this approach better than I. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073
DBD::Sybase ping issue
I suggest changing the DBD::Sybase ping statement which is totally inefficient. Currently it's: select * from sysusers where 1=2 I suggest the usual select 1, which in my profiling averages 10x faster than the above. Would there be any reason to use the sysusers table except to check that it exists? In any case, without sysusers, Sybase ASE won't even run. --- Henri Asseily [EMAIL PROTECTED] Chief Technology Officer BizRate.com Que les inopérants laissent passer ceux qui font Achille Talon
Re: DBD::Sybase ping issue
On Mon, 2002-10-21 at 14:51, Henri Asseily wrote: I suggest changing the DBD::Sybase ping statement which is totally inefficient. Currently it's: select * from sysusers where 1=2 I suggest the usual select 1, which in my profiling averages 10x faster than the above. Good idea. Thanks. Michael -- Michael Peppler / [EMAIL PROTECTED] / http://www.mbay.net/~mpeppler [EMAIL PROTECTED] / ZetaTools, Inc / http://www.zetatools.com ZetaTools: Call perl functions as Sybase stored procedures! signature.asc Description: This is a digitally signed message part
Re: DBD::Pg up for sale
On Mon, Oct 21, 2002 at 09:35:10AM +0200, Joern Reder wrote: Bruce Momjian wrote: I would like to avoid subscribing to another list, especially since I don't know much about Perl or DBD. Perhaps you folks can work together on that list and just send PostgreSQL-specific questions to me or the gborg list. Don't want to be heretical, but how can you take over maintainership of DBD::Pg if you're no Perl programmer? Or did I miss something? Frankly I doubt it's practical to be a DBI driver developer without being on the DBI driver developer mailing list. Tim.
Re: DBD:pg outstanding patches
On Monday, October 21, 2002, at 11:42 AM, Bruce Momjian wrote: In that case, I suggest the attached, even more simplified patch. It assumes that the quote character stored in $lp in the existing version is always ' (a safe assumption for DBD:Pg, I think, in a way it wasn't for DBI, from whence the code for the LITERAL_PREFIX and LITERAL_SUFFIX was copied into DBD::Pg), and therefore performs the escaping of the three agreed-upon characters for all non-numeric data types. A variation of this patch was applied to DBD::Pg by Jeffrey Baker and included in version 1.10 or 1.11 and later. However, Jeffrey did point out that it might in fact make more sense (and faster) to use the PQescapeString() function in C. Anyone want to volunteer a patch? I can't speak to the other patches, though. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
DBD:pg outstanding patches
Here is a mailbox file that contains DBD:pg patches I have collected
over the years. I am sure many have not made it into the official
distribution.
Let me know if you have trouble reading it.
On a related note, someone questioned why I am the DBD:pg maintainer
if I don't know Perl. In fact, I am only the coordinator of the
project. I will do little coding and mostly just assist others in
coding, reviewing patches, and making releases. I don't want to have
_a_ maintainer of DBD:pg. This is an open source project so I don't
want all the work to have to filter through a single person. I think
this has caused the DBD:pg module to languish in the past.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
From pgman Mon Jun 11 18:16:47 2001
Return-path: pgman
Received: (from pgman@localhost)
by candle.pha.pa.us (8.10.1/8.10.1) id f5BMGkB19047
for pgman; Mon, 11 Jun 2001 18:16:46 -0400 (EDT)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA00195
for [EMAIL PROTECTED]; Sat, 24 Feb 2001 01:25:00 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f1O6N5x72567;
Sat, 24 Feb 2001 01:23:05 -0500 (EST)
(envelope-from [EMAIL PROTECTED])
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f1O4Wkx51637
for [EMAIL PROTECTED]; Fri, 23 Feb 2001 23:32:46 -0500 (EST)
(envelope-from [EMAIL PROTECTED])
Received: from pippin.salon.com (pippin.salon.com [208.48.211.66])
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f1NMgHx17867
for [EMAIL PROTECTED]; Fri, 23 Feb 2001 17:42:17 -0500 (EST)
(envelope-from [EMAIL PROTECTED])
Received: from localhost (garth@localhost)
by pippin.salon.com (8.9.3/8.9.3) with ESMTP id OAA31820
for [EMAIL PROTECTED]; Fri, 23 Feb 2001 14:42:06 -0800
X-Authentication-Warning: pippin.salon.com: garth owned process doing -bs
Date: Fri, 23 Feb 2001 14:42:06 -0800 (PST)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Handling of large objects in DBD::Pg? (fwd)
In-Reply-To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY=8323328-1172321252-982968126=:30639
Precedence: bulk
Sender: pgman
Status: OR
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to [EMAIL PROTECTED] for more info.
--8323328-1172321252-982968126=:30639
Content-Type: TEXT/PLAIN; charset=US-ASCII
Attached are large object read and write functions I wrote based on
information I gleened from the DBD::Pg install test script.
They read and write to buffers rather than files because my
information wasn't comming from a file and wasn't going to one. However
if you need the data to go to a file you can either open a file handle
yourself in these methods and read into a scalar or write out from one, OR
you can scan the test.pl file in the DBD::Pg install to see how to use the
proper file based read and write Pg calls.
M. Tavasti [EMAIL PROTECTED] wrote:
How do I handle large objects in DBD:Pg (perl DBI interface to
postgresql)?
I've tried to do like this, but not successfull, it looks like there
is no data inserted. I tried to see in psql is there something, doing
SELECT lo_export(data,/tmp/foofaa.txt) from foofaa where id=;
$obj_ins = $dbh-prepare(q{
INSERT INTO foofaa
(id,entry,data)
VALUES
(?,?,?)});
$obj = $dbh-func(./$dir/obj.txt, 'lo_import');
$obj_ins-execute($id,$ent,$obj);
Manual page of DBD:Pg if confusing for lo_export:
$ret = $dbh-func($lobjId, 'lo_export');
Exports a large object into a Unix file. Returns
false upon failure, true otherwise.
To what file
Any help welcome.
--8323328-1172321252-982968126=:30639
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=lotest.pl
Content-Transfer-Encoding: BASE64
Content-ID: [EMAIL PROTECTED]
Content-Description: Large Object access functions
Content-Disposition: attachment; filename=lotest.pl
IyEvdXNyL2Jpbi9wZXJsIC13DQoNCnVzZSBzdHJpY3Q7DQoNCnVzZSBEQkk7
DQp1c2UgREJEOjpQZzsNCg0KbXkgJGRzbiA9ICJkYm5hbWU9cDEiOw0KbXkg
JGRiaCA9IERCSS0+Y29ubmVjdCgnZGJpOlBnOmRibmFtZT1wMScsIHVuZGVm
LCB1bmRlZiwgeyBBdXRvQ29tbWl0ID0+IDEgfSk7DQoNCm15ICRidWYgPSAn
YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHggNDAwOw0KDQpteSAkaWQg
PSB3cml0ZV9ibG9iKCRkYmgsIHVuZGVmLCAkYnVmKTsNCg0KbXkgJGRhdCA9
IHJlYWRfYmxvYigkZGJoLCAkaWQpOw0KDQpwcmludCAiRG9uZVxuIjsNCg0K
Re: DBD::Pg up for sale
I have to agree with the question of how you plan on taking over DBD::Pg if your no prel programmer. That has got to be the craziest thing I ever heard. I hope that someone else takes it over, I will voluntier, as I am a perl programmer that uses DGD:Pg on a regular basis. I cant afford for someone who is not a perl programer to take over this module, who also does not want to subscribe to the DBI driver mailing list. On Mon, 2002-10-21 at 08:26, Tim Bunce wrote: On Mon, Oct 21, 2002 at 09:35:10AM +0200, Joern Reder wrote: Bruce Momjian wrote: I would like to avoid subscribing to another list, especially since I don't know much about Perl or DBD. Perhaps you folks can work together on that list and just send PostgreSQL-specific questions to me or the gborg list. Don't want to be heretical, but how can you take over maintainership of DBD::Pg if you're no Perl programmer? Or did I miss something? Frankly I doubt it's practical to be a DBI driver developer without being on the DBI driver developer mailing list. Tim. -- Thanks, Harvey Cary CISSP, MCSE+I [EMAIL PROTECTED] http://www.opsecurity.com
DBD-pg outstanding patches
Here is a mailbox file that contains patches I have collected for DBD:pg over the years: ftp://candle.pha.pa.us/pub/postgresql/dbd I am sure many have not made it into the official distribution. Let me know if you have trouble reading it. On a related note, someone questioned why I am the DBD:pg maintainer if I don't know Perl. In fact, I am only the coordinator of the project. I will do little coding and mostly just assist others in coding, reviewing patches, and making releases. I don't want to have _a_ maintainer of DBD:pg. This is an open source project so I don't want all the work to have to filter through a single person. I think this has caused the DBD:pg module to languish in the past. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073
DBD::Pg Going Forward (Was: DBD::Pg up for sale)
On Monday, October 21, 2002, at 05:26 AM, Tim Bunce wrote: Frankly I doubt it's practical to be a DBI driver developer without being on the DBI driver developer mailing list. I think this is true, and in discussing this issue with Bruce, I realized that there was a mistaken perception about the role he wishes to play in the continuing development of DBD::Pg. Bruce created the GBorg project for DBD::Pg so that there'd be easy CVS access for interested parties to download the source and make patches, not to take over development himself. My understanding is that he's more interested in being a kind of administrator for DBD::Pg while allowing others (i.e., dbi-dev folks and interested DBD::Pg users) to continue development in a collaborative manner. I think that part of the misunderstanding comes out of the different cultures of the PostgreSQL and Perl communities. The PostgreSQL developers have no maintainer, no Pumpking, no Poobah. They work together on issues that interest them, come to consensus, and then commit changes. This is the kind of approach that Bruce wants to encourage for DBD::Pg development, in part to get away from DBD::Pg's historically slow development under a single developer who might lack the time to respond to patches and get out new releases.* So I'd like to propose this plan going forward: All patches and discussion of DBD::Pg should continue on dbi-dev, Cc'ing Bruce and/or the PostgreSQL interfaces list when it makes sense to get feedback on our use of the PosgreSQL API. Once consensus is reached with regard to proposed patches and development directions, someone with commit access to the CVS repository will make the necessary commits (a list of such folks is on the DBD::Pg GBorg page, http://gborg.postgresql.org/project/dbdpg/projdisplay.php?172). And again, when consensus comes together that we're ready for release, I'll function as a release manager of sorts, create a distribution, and upload it to the CPAN. Bruce will announce releases and such on the GBorg dbdpg-general list. Ultimately, I think that this approach will facilitate future DBD::Pg development, because many more people can now easily participate and, as a PostgreSQL core developer, Bruce can offer a wealth of knowledge regarding the the PostgreSQL API. I hope that this clears things up enough that we can all work together to make DBD::Pg the best written, best-supported DBI driver on the CPAN. Regards, David * This is not intended as a slam against the previous DBD::Pg developers -- hey, we owe it to them that DBD::Pg exists in the first place! Thanks, guys! -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: DBD::Pg up for sale
I totally agree with this. There are already 4 developers on the project: http://gborg.postgresql.org/project/dbdpg/projdisplay.php I will do as little as possible, just making sure development is moving along and user requests are addressed. We have done a similar thing with the PostgreSQL jdbc driver, where two people are now doing most of the development and patch application. --- Jason E. Stewart wrote: Elizabeth Mattijsen [EMAIL PROTECTED] writes: What I know of DBD drivers, I too think it would be madness for someone to have to maintain these without a thorough knowledge of Perl _and_ DBI. Probably well intended madness, but still madness. Once the driver is maintained through a sourceforge-like project, it matters less who is the *maintainer*, it matters more who the developers are. Hosting it out of the Postgres development site makes sense, and having one of the main Postgres developers associated with the driver development also makes sense. His lack of interest in Perl and DBI in general does suggest at least having a co-maintainer more versed in Perl/DBI. I don't care where the project lives, I just care that it be maintained in an open CVS repostitory at a project site in which interested developers can join and help the project. Having to funnel all patches through a single maintainer has consistently not worked for the entire history of DBD::Pg. I joined up two days ago, got approved, checked out the code and am testing my changes to the table_info() method. I'll post my ideas here. My advice is to joing the project, write documentation, write tests, write code, or help out the project in any way you can. Less politics, more coding. jas. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073
Re: DBD:pg outstanding patches
Rudy Lippan wrote: On Mon, 21 Oct 2002, David Wheeler wrote: Date: Mon, 21 Oct 2002 12:18:17 -0700 From: David Wheeler [EMAIL PROTECTED] To: Bruce Momjian [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: DBD:pg outstanding patches On Monday, October 21, 2002, at 11:42 AM, Bruce Momjian wrote: A variation of this patch was applied to DBD::Pg by Jeffrey Baker and included in version 1.10 or 1.11 and later. However, Jeffrey did point out that it might in fact make more sense (and faster) to use the PQescapeString() function in C. Anyone want to volunteer a patch? Lest anyone forget, He also said that PQescapeString is a fairly new feature of postgres (7.1 || 7.2), and that by switching over we would be cutting everone else off. So we will probably need to keep track of the version of postgres (compile time /| run time) used and call either the postgres API function or a DBD::Pg supplied function as needed. Yes PQescapeString was new in 7.2, released 2002-02-04. Not sure how DBD-pg calls libpq, but if PQescapeString is in libpq, you can use it, if not, you will have to roll your own. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073
Re: DBD::Pg up for sale
Bruce Momjian [EMAIL PROTECTED] writes: Now, with that out of the way, why does there have to be one maintainer? We don't have one PostgreSQL server maintainer, and it seems crazy to push all changes to DBD:pg through a single person. At PostgreSQL, we have a collaborative effort, where people post patches, others comment, and when a consensus is reached, the patch is applied. I plan to do very little with DBD-pg except to make sure things are running smoothly within the group of DBD-pg developers, and I will see they get any PostgreSQL information they need. I agree. Thanks bruce, for jumping in and setting up the dbdpg project at gborg. jas.
Re: DBD:pg outstanding patches
David Wheeler wrote: On Monday, October 21, 2002, at 01:45 PM, Dave Rolsky wrote: BTW, There's also a PQescapeBytea which might fix consistent problems I've had trying to insert binary data into a BYTEA column (I ended up just base64 encoding it, but that's lame). Oh, I wasn't aware that was an issue. My Perl implementation of quote() is supposed to handle that. Using PQescapeBytea is probably the right thing to do for BYTEA, and PQescapeString for other strings. Bruce, when was PQescapeBytea introduced? 7.3beta, meaning it isn't even officially out yet. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073
Re: DBD:pg outstanding patches
On Monday, October 21, 2002, at 01:28 PM, Bruce Momjian wrote:
Yes PQescapeString was new in 7.2, released 2002-02-04. Not sure how
DBD-pg calls libpq, but if PQescapeString is in libpq, you can use it,
if not, you will have to roll your own.
Well, right now, DBD::Pg::quote() is pure Perl, and looks like this:
my %esc = ( ' = '\\047', # '\\' . sprintf(%03o, ord(')), #
ISO SQL 2
'\\' = '\\134', # '\\' . sprintf(%03o, ord(\\)),
\0 = '\\000' # '\\' . sprintf(%03o, ord(\0)),
);
sub quote {
my ($dbh, $str, $data_type) = @_;
return NULL unless defined $str;
return $str if $data_type $no_escape[$data_type];
$str =~ s/(['\\\0])/$esc{$1}/g;
return '$str';
}
This seems to work just fine. So if want to just leave it like this
until such time as we're ready to declare the minimum installation of
PostgreSQL to be 7.2, I think it'll continue to work fine.
If, OTOH, DBD::Pg can determine what's available and what's not when
it's compiled, we can use the above for pre 7.2 and PQescapeString for
7.2 or later.
It looks like I might soon need to find the tuits to learn enough C and
XS to be able to supply patches for such an idea. :-)
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: DBD::Pg Going Forward (Was: DBD::Pg up for sale)
Rudy Lippan wrote: On Mon, 21 Oct 2002, David Wheeler wrote: I think that part of the misunderstanding comes out of the different cultures of the PostgreSQL and Perl communities. The PostgreSQL developers have no maintainer, no Pumpking, no Poobah. They work together on issues that interest them, come to consensus, and then commit changes. This is the kind of approach that Bruce wants to encourage for DBD::Pg development, in part to get away from DBD::Pg's historically slow development under a single developer who might lack the time to respond to patches and get out new releases.* This sounds very unperllike to me, and, of course, DBD::Pg is a perl module. Well, if your single-maintainer perl-like way hasn't worked well in the past, you may went to reconsider that approach. I don't see why you would want to bottleneck the whole thing in one person when you can have a group leveraging their talent/time. Maybe we should let Tim decide if we should have a maintainter in the perl community? And besides has Jeffrey Baker officially abdicated? As it seems that you have responded to the problem that he was having viz., about not being able to conatact any of the PostgreSQL developers. I think Jeffrey had the reverse problem of what you are seeing, that the DBD:pg guy wasn't involved in the PostgreSQL development process, and hence didn't receive patches submitted to PostgreSQL patches list nor subscribe to any of our email lists where he could discuss things. The goal now is to have a group that stradles dbi-dev and PostgreSQL lists and have the group work in a more coordinated fashion. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073
Re: DBD::Pg Going Forward (Was: DBD::Pg up for sale)
On Monday, October 21, 2002, at 02:47 PM, Tim Bunce wrote: With the proviso that any issues that affect the user visible behaviour are discussed on dbi-dev, and that the majority of DBD::Pg developers are subscribed to the list. Since I suggested that all development discussion take place on dbi-dev, I'm reasonable confident that this is exactly what will happen. :-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: DBD::Pg up for sale
On Mon, Oct 21, 2002 at 01:50:25PM -0600, Jason E. Stewart wrote: I joined up two days ago, got approved, checked out the code and am testing my changes to the table_info() method. I'll post my ideas here. I just uploaded a patch that begins adding meta data support to DBD::Pg based on DBI spec. It includes an enhance table_info method. T -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
