X-Original-To: pgsql-hackers@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 5EE45476349 for ; Tue, 29 Apr 2003 15:37:42 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 9954647631B for ; Tue, 29 Apr 2003 15:37:06 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h3TJYbU6004981; Tue, 29 Apr 2003 15:34:37 -0400 (EDT) To: Peter Eisentraut Cc: PostgreSQL Development Subject: Re: Transform groups In-reply-to: References: Comments: In-reply-to Peter Eisentraut message dated "Tue, 29 Apr 2003 19:58:48 +0200" Date: Tue, 29 Apr 2003 15:34:36 -0400 Message-ID: <4980.1051644876@sss.pgh.pa.us> From: Tom Lane X-Spam-Status: No, hits=-31.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NO_DNS_FOR_FROM, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/983 X-Sequence-Number: 38473 Peter Eisentraut writes: > The SQL standard defines a concept called "transform groups", which are > basically pairs of input/ouput functions that can be switched between. > Is this something worth investigating? Perhaps, but there is little time left to get it done for 7.4. Can we lay out a strategy that will let us add such things incrementally, without another protocol break later? What I had personally been planning to do was restore the typsend and typreceive columns of pg_type, defined on the order of typsend(mytype) returns bytea typreceive(bytea) returns mytype and then define some simple conventions, probably network-byte-order based, that these functions would be expected to adhere to for the external binary representation. The on-the-wire representation is a network-byte-order length followed by whatever contents the send routines put into their bytea results. I don't think this would scale very well to multiple external representations, though; sure you could define a switch somewhere, but what are the odds that N different send/receive functions would all pay attention to it? And how would you know if they didn't? The implementations of these functions would probably mostly depend on a small set of conversion routines similar to the existing pq_getint and pq_putint routines, so it might be possible to do simple things like switching endianness in a centralized way. But I'm not sure what happens if you want bigger changes than that. regards, tom lane