Pgwire

Pgwire implements the PostgreSQL protocol version 3.0 natively in Tcl script, allowing connection to a PostgreSQL server from anywhere that has a Tcl interpreter with no external library or driver requirements. As an optional enhancement, if the jitc extension is present, pgwire will use it to build accelerators for the most performance critical portions of code (mainly parsing data row responses). With jitc present, pgwire is faster than tdbc::postgres. In pure Tcl script mode it is generally equivalent to tdbc::postgres performance except in cases where result sets contain a large number of columns or rows.

If the unix_sockets extension is available, pgwire can connect to the UDS interface of the PostgreSQL server on the local host, which offers a considerable latency advantage over a loopback (localhost) TCP connection.

Pgwire leverages its low-level protocol implementation to provide access to features of PostgreSQL that are not easily accessible to clients built on top of libpq, like:

• robust LISTEN / NOTIFY support (with full asynchronous push support)
• implicit prepared statement caching for all queries (with transparent re-prepare when a schema change invalidates a cached plan)
• binary (native PostgreSQL format) transport of query parameters and row results (including PostgreSQL arrays)
• COPY FROM support for efficient loading of bulk data (with COPY TO planned): COPY FROM example
• streaming of large result sets so that unlimited result set sizes can be processed in Tcl scripts without the requirement to allocate storage for all rows up-front (with transparent buffering of outer results when nesting queries)
• supplying parameters to the startup message, so that parameters like application_name can be set to tag a connection for stats reporting or debugging
• detaching from a thread and re-attaching to a different thread, allowing database connection pools to be implemented in multithreaded applications
• nestable transaction support
• connection-state aware quoting for values and names to allow safe interpolation in SQL query strings (but use proper parameters where possible)
• introspection of the protocol state: transaction state, ready-for-query and the current state of server parameters