FW: [HACKERS] Re: [INTERFACES] Re: libpgtcl.dll for Windows
От | Dan Gowin |
---|---|
Тема | FW: [HACKERS] Re: [INTERFACES] Re: libpgtcl.dll for Windows |
Дата | |
Msg-id | 43A3A1806104D211988500A0C9B576EE7CE003@avantec_exc.avantec.net обсуждение исходный текст |
Список | pgsql-hackers |
-----Original Message----- From: Dan Gowin Sent: Tuesday, December 08, 1998 11:46 AM To: 'Tom Lane'; Pgsql Core (E-mail) Subject: RE: [HACKERS] Re: [INTERFACES] Re: libpgtcl.dll for Windows Tom,We ran into the same problem your describing with the Tcl code and developed the following solution.At my company we built a special library that converts the "C" data types that the Postgres engine uses and converts them into Tcl datatypes. We then used this base to build a listener that runs on the UNIX machine that only talks Tcl to other Tcl interpreters. This way, the only thing we need to move around from platform to platform is Tcl library code for doing front ends. What does this all mean? We currently have Tcl/Tk interfaces for our RakenSQL servers that come on a RakenSQL Client CD-ROM for interface development. And we currently are developing a developers version that we will give away for free (2Q 99) to the development community. But there is a problem. The Tcl extensions we use are not the same as those chosen for "libpgtcl". Instead of using an interface that resembles one of the "ProC" pre compilers for Oracle, were the SQL is passed as a string to a function. And a cursor is used to loop through the resulting data. We built SQL into our library as an extension to the Tcl language. We built five main commands, with each having multiple command options. login, logout, sql, query, and sys. For example: "login" on a GUI system will display a login window, if no commands are passed to it. "logout" signs off that connection thread. "sql" can be passed SQL queries with the result returned as Tcl lists and the database column titles are the names of the lists. "query" will return the results of a SQL query in ascii table format for use on the Tcl/Tl command console. And "sys" is used for our remote management channel for doing remote commands like "backup", "reboot", "shutdown", "ps", "netstat", "restore" and "datetime". The "query" command still has an interface that returnsa cursor to the user. We put this in there just incase the user needs to have quicker access to larger data sets (It can take some time to form very large Tcl list on Win95 systems). Unfortunately, none of this works with pgAccess. We tried doing some hacking on pgAccess, but even if we use an unmodified Tcl/Tk interpreter and add simple blank lines after "if" statements, the interpreter core dumps. Also, our GUI login routine is setup with passwords and the database that is being logged into. For example: login postgres dd34rf8 master_server template1 Is a login that does not use our built in GUI login window. We are using the latest pgAccess and we develop with Tcl/Tk 8.1 with the latest patches from John Ousterhout. mailto:john.ousterhout@scriptics.com Just my two cents. Dan Gowin -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Tuesday, December 08, 1998 9:59 AM To: Constantin Teodorescu Cc: Pgsql-Interfaces; PostgreSQL Hacker Subject: [HACKERS] Re: [INTERFACES] Re: libpgtcl.dll for Windows Constantin Teodorescu <teo@flex.ro> writes: > Joost Kraaijeveld wrote: >>>> PS. A lot of people are asking me if there is a libpgtcl.dll for M$ >>>> Windows. The pgtcl package, written in pure Tcl/Tk is working but it's >>>> very slooooow. Is there any chance that someone could try to port the >>>> libpgtcl library for Windows ? >> I tried but the functions >> Tcl_CreateFileHandler(/usr/src/pgsql/src/interfaces/libpgtcl/pgtclId.c:6 79) >> and Tcl_DeleteFileHandler >> (/usr/src/pgsql/src/interfaces/libpgtcl/pgtclId.c:701) were removed for >> non-Unix platforms as of tcl/tk8.0b1 (or thereabouts). OK, I'm to blame for that code... > I don't know where that functions are used, but if they are used in > functions concerning large objects, Large objects aren't the issue; support for async NOTIFY is. The comments at the head of pgtclId.c explain: Another headache is that Ousterhout keeps changing the Tcl I/O interfaces. libpgtcl currently claims to work with Tcl 7.5, 7.6, and 8.0, and each of 'em is different. Worse, the Tcl_File type went away in 8.0, which means there is no longer any platform-independent way of waiting for file ready. So we now have to use a Unix-specific interface. Grumble. In the current design, Pg_Notify_FileHandler is a file handler that we establish by calling Tcl_CreateFileHandler(). Itgets invoked from the Tcl event loop whenever the underlying PGconn's socket is read-ready. We suck up any available data (to clear the OS-level read-ready condition) and then transfer any available PGnotify events into the Tcl event queue. Eventually these events will be dispatched to Pg_Notify_EventProc. When we do an ordinary PQexec, we must also transfer PGnotify events into Tcl's event queue, since libpq might have read them when we weren't looking. If anyone can explain to me a platform-independent way of waiting for socket-read-ready under Tcl 8.0, I'd gladly incorporate it. I suppose the other alternative is to insert a bunch of "#ifdef WIN32" code to provide a platform-specific implementation of this functionality for Windows. But I'm not sure what that would be, and I'm in no position to write or test it anyway. Volunteers? (If you don't need NOTIFY functionality, it'd probably be possible just to #ifdef out the filehandler and associated setup code... but I don't see that as a reasonable solution for general use.) regards, tom lane
В списке pgsql-hackers по дате отправления: