X-Original-To: pgsql-hackers@postgresql.org Received: from news.hub.org (news.hub.org [64.49.215.80]) by postgresql.org (Postfix) with ESMTP id 8BEE2475AD4 for ; Fri, 14 Mar 2003 13:06:17 -0500 (EST) Received: by news.hub.org (Postfix, from userid 8) id 6CE7743A611; Fri, 14 Mar 2003 13:06:17 -0500 (EST) X-Newsgroups: comp.databases.postgresql.hackers Subject: Re: Roadmap for FE/BE protocol redesign From: Christopher Browne X-Home-Page: http://www.cbbrowne.com/info/ X-Affero: http://svcs.affero.net/rm.php?r=cbbrowne X-Emacs-Acronym: Every Mode Accelerates Creation of Software Microsoft: I'm not laughing anymore. X-Uboat-Death-Message: TORPEDOED BY IRC SERVER. DEPTH CHARGES. SINKING. U-971. References: <87r89ac6s4.fsf@stark.dyndns.tv> Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) XEmacs/21.4 (Portable Code, linux) Cancel-Lock: sha1:UF8awAW460EerFIiZnaLd9nRYnw= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 35 Date: Fri, 14 Mar 2003 12:07:30 -0500 X-Complaints-To: abuse@sympatico.ca Organization: Bell Sympatico To: pgsql-hackers@postgresql.org X-Archive-Number: 200303/621 X-Sequence-Number: 36867 A long time ago, in a galaxy far, far away, gsstark@mit.edu (Greg Stark) wrote: > So, just to throw out a wild idea: If you're talking about making large > changes to the on-the-wire protocol. Have you considered using an existing > database protocol? This would avoid having to reinvent the wheel every time > postgres implements a new feature like prepared queries, bind arrays, or > metadata information. > > There is a free implementation of the TDS (Tabular DataStream) protocol used > by Sybase and MSSQL. I don't know how much of it would be interesting for > postgres and how much is Sybase/MSSQL-specific. > > It would be pretty neat if postgres could use precisely the same on-the-wire > protocol as other major databases, just requiring a separate high level driver > to interpret the semantic meaning of the data. > > At the very least it sounds like interesting to do a compare and contrast as > far as understanding what advantages the features TDS has have and what > disadvantages, before postgres possibly misses good ideas or makes the same > mistakes. Let me take the liberty of pointing people to documentation to the TDS protocol: I agree that there are far worse ideas, when opening up the DB protocol, than to look at some existing protocols, and TDS would seem a reasonable one. It doesn't look overly efficient, but it's not overtly gratuitously inefficient... -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www.ntlug.org/~cbbrowne/linuxxian.html DOS: n., A small annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by Unix. See also MS-DOS, IBM-DOS, DR-DOS. -- from David Vicker's .plan