Thread: Announce: A pure-Tcl interface to PostgreSQL
Announcing the first public release of a Tcl interface to PostgreSQL which is written entirely in Tcl. It is mostly but not entirely command-compatible with libpgtcl, and should run everywhere Tcl runs with no compilation needed. For more information see: http://gborg.postgresql.org/project/pgintcl/ The current release 1.3.9 is available for download. Before you ask, it does not yet work with PGAccess. When there is a stable, working version of PGAccess, I will provide a patch to PGAccess for it.
On Sat, 15 Feb 2003, ljb waxed: > Announcing the first public release of a Tcl interface to PostgreSQL > which is written entirely in Tcl. It is mostly but not entirely > command-compatible with libpgtcl, and should run everywhere Tcl runs > with no compilation needed. Hooray ! > For more information see: http://gborg.postgresql.org/project/pgintcl/ > The current release 1.3.9 is available for download. I'm just curious how you got to 1.3.9 without a public release... > Before you ask, it does not yet work with PGAccess. When there is a stable, > working version of PGAccess, I will provide a patch to PGAccess for it. If you need help just starting PgAccess, please use our support@pgaccess.org email. We could always use some more Tcl coders. But in regards to the "README.PgAccess" file included in the pgintcl download and the "known issues" with PgAccess and pgin.tcl : 1. Loading - easy, like you said 2. Connecting - easy, except your code will break UDS and force TCP/IP 3. Import/Export - easy if you force the wizard when you decide to use pgin.tcl, as the wizard uses SELECT/INSERT vs. the old COPY Given that #2 and #3 would change behavior of PgAccess, I would recommend that the use of any patch for pgin.tcl be available as a command-line option. This way, users could specify whether they want to use libpgtcl or pgin.tcl, and we could code around it where necessary. --Chris -- Chris Maj <cmaj_hat_freedomcorpse_hot_info> 0xC0051F6A 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A
cmaj@freedomcorpse.info wrote: > ... > > For more information see: http://gborg.postgresql.org/project/pgintcl/ > > The current release 1.3.9 is available for download. > > I'm just curious how you got to 1.3.9 without a public release... By working on it for 4-1/2 years and bumping the version when anything significant changed. It was being used "internally", but I didn't think there was much was interest in it. When gborg.postgresql.org come along, that seemed like a good place for it. >... > But in regards to the "README.PgAccess" file included in the pgintcl > download and the "known issues" with PgAccess and pgin.tcl : > > 1. Loading - easy, like you said > 2. Connecting - easy, except your code will break UDS and force TCP/IP > 3. Import/Export - easy if you force the wizard when you decide to use > pgin.tcl, as the wizard uses SELECT/INSERT vs. the old COPY > > Given that #2 and #3 would change behavior of PgAccess, I would > recommend that the use of any patch for pgin.tcl be available as a > command-line option. This way, users could specify whether they want to > use libpgtcl or pgin.tcl, and we could code around it where necessary. I planned to include a patch to PgAccess in with pgin.tcl. I don't think applying the patch would break use of PgAccess with libpgtcl, because the changes are compatible. For example, after COPY, I need a call to pg_endcopy, but it can be made conditional on {[info procs pg_endcopy]!=""}. Item #2 doesn't even need code changes; yes, it has to use TCP not UDS but pgin.tcl does it automatically if you don't specify a hostname. I wanted to include this patch with the first release of pgin.tcl, but I got frustrated and gave up. I tried both pgaccess-0.98.8 and 0.98.8.20030117, with PostgreSQL-7.3.2, and I could not get them to work (this is with libpgtcl, not my code). Some of the problems that bit me in the first few minutes are on bugzilla.pgaccess.org, like: Schema-qualified quoting problem (PgAccess bug #64),Fails trying to access pg_shadow (PgAccess bug #91), Hides PostgreSQL error messages (PgAccess bug #69). There were others, which I didn't find in the bugzilla, but they could be just side effects of other errors. Sorry, but I just decided to wait. I'm looking forward to a PgAccess release that addresses some of the ~50 bug reports currently on bugzilla.pgaccess.com.
On Tue, 18 Feb 2003, ljb waxed: > cmaj@freedomcorpse.info wrote: > > ... > > > For more information see: http://gborg.postgresql.org/project/pgintcl/ > > > The current release 1.3.9 is available for download. > > > > I'm just curious how you got to 1.3.9 without a public release... > > By working on it for 4-1/2 years and bumping the version when anything > significant changed. It was being used "internally", but I didn't think > there was much was interest in it. When gborg.postgresql.org come along, > that seemed like a good place for it. Maybe I missed it in the docs, but what backend protocols does 1.3.9 support ? > >... > > But in regards to the "README.PgAccess" file included in the pgintcl > > download and the "known issues" with PgAccess and pgin.tcl : > > > > 1. Loading - easy, like you said > > 2. Connecting - easy, except your code will break UDS and force TCP/IP > > 3. Import/Export - easy if you force the wizard when you decide to use > > pgin.tcl, as the wizard uses SELECT/INSERT vs. the old COPY > > > > Given that #2 and #3 would change behavior of PgAccess, I would > > recommend that the use of any patch for pgin.tcl be available as a > > command-line option. This way, users could specify whether they want to > > use libpgtcl or pgin.tcl, and we could code around it where necessary. > > I planned to include a patch to PgAccess in with pgin.tcl. I don't think > applying the patch would break use of PgAccess with libpgtcl, because the > changes are compatible. For example, after COPY, I need a call to > pg_endcopy, but it can be made conditional on {[info procs pg_endcopy]!=""}. > Item #2 doesn't even need code changes; yes, it has to use TCP not UDS but > pgin.tcl does it automatically if you don't specify a hostname. Well, sure, if something is funky, we can code around it. > I wanted to include this patch with the first release of pgin.tcl, but I > got frustrated and gave up. I tried both pgaccess-0.98.8 and > 0.98.8.20030117, with PostgreSQL-7.3.2, and I could not get them to > work (this is with libpgtcl, not my code). Some of the problems that > bit me in the first few minutes are on bugzilla.pgaccess.org, like: > Schema-qualified quoting problem (PgAccess bug #64), > Fails trying to access pg_shadow (PgAccess bug #91), > Hides PostgreSQL error messages (PgAccess bug #69). > There were others, which I didn't find in the bugzilla, but they could be > just side effects of other errors. Sorry, but I just decided to wait. > I'm looking forward to a PgAccess release that addresses some of the ~50 > bug reports currently on bugzilla.pgaccess.com. Ahh, bugzilla and quantitative analysis ! But sometimes numbers lie... Many of these, you will find, are feature requests and other wishlist items. We also have a todo list and known bugs list in CVS. Sort of the more developer-centric stuff. And actually, for some of them, like MD5 authentication, your code could really help us out. Besides that, many of those bugs have been around since before the new team adopted the project, just nobody kept track as good as we do. Please, let me know on/off list what we can do to at least get PgAccess running for you. I would be more than happy to help integrate this patch. I think it's something we can do before we get a "perfect" release of a cross-platform RAD and DBA toolkit for PostgreSQL. :) --Chris -- Chris Maj <cmaj_hat_freedomcorpse_hot_info> 0xC0051F6A 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A
cmaj@freedomcorpse.info wrote: > ... > Maybe I missed it in the docs, but what backend protocols does 1.3.9 > support ? Only the current one, "v2.0", which talks to PostgreSQL-6.4 through at least 7.3.2. (My very first versions talked "v1" to PostgreSQL-6.3.x) I hear a protocol change is coming with PostgreSQL-7.4. I'm hoping there will be a backward-compatible release or two for transition, as there was the last time, and that the protocol won't undergo any extreme radical changes. Of course, this affects the ODBC and JDBC interfaces, too, and they are much larger and presumably harder to update to a new protocol. > Please, let me know on/off list what we can do to at least get PgAccess > running for you. I would be more than happy to help integrate this > patch. I think it's something we can do before we get a "perfect" > release of a cross-platform RAD and DBA toolkit for PostgreSQL. :) OK. Let's continue this on developers at pgaccess.org.