pg.ddx.io pgsql-interfaces@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Transform groups 2+ messages / 2 participants [nested] [flat]
* Transform groups @ 2003-04-29 17:58 Peter Eisentraut <peter_e@gmx.net> 0 siblings, 1 reply; 2+ messages in thread From: Peter Eisentraut @ 2003-04-29 17:58 UTC (permalink / raw) To: PostgreSQL Development <pgsql-hackers@postgresql.org> There was some talk in the context of the new protocol to do some enhancements in the area of the "binary" format to make it useful across different architectures etc. The SQL standard defines a concept called "transform groups", which are basically pairs of input/ouput functions that can be switched between. The standard talks about different transform groups for different host languages, so this essentially selects between different binary output formats. I think this would fit naturally with many things we are doing and want to do. We could have a (default) "text" transform group, a "binary little endian" transform group, a "binary big endian" transform group". Transform groups could map more sophisticated data types into native programming language structures (think timestamp or inet). Users could also plug in their own transform groups for existing data types if they hate the input or output format. It would also reduce the pressure to add more ad-hoc format-twiddling parameters like extra_float_digits or even datestyle. Is this something worth investigating? -- Peter Eisentraut peter_e@gmx.net ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Transform groups @ 2003-04-29 19:34 Tom Lane <tgl@sss.pgh.pa.us> parent: Peter Eisentraut <peter_e@gmx.net> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2003-04-29 19:34 UTC (permalink / raw) To: Peter Eisentraut <peter_e@gmx.net>; +Cc: PostgreSQL Development <pgsql-hackers@postgresql.org> Peter Eisentraut <peter_e@gmx.net> 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 ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2003-04-29 19:34 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2003-04-29 17:58 Transform groups Peter Eisentraut <peter_e@gmx.net> 2003-04-29 19:34 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox