Re: Let's drop V2 protocol

Marko Kreen <markokr@gmail.com>

From: Marko Kreen <markokr@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Merlin Moncure <mmoncure@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>, greg@2ndquadrant.com, pgsql-hackers@postgresql.org, shigeru.hanada@gmail.com
Date: 2012-02-24T17:11:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix COPY FROM for null marker strings that correspond to invalid encoding.

  2. Improve labeling of pg_test_fsync open_sync test output.

On Fri, Feb 24, 2012 at 11:46:19AM -0500, Tom Lane wrote:
> As for taking it out of libpq, I would vote against doing that as long
> as we have pg_dump support for pre-7.4 servers.  Now, I think it would
> be entirely reasonable to kill pg_dump's support for pre-7.3 servers,
> because that would simplify life in numerous ways for pg_dump; but 7.4
> was not a big compatibility break for pg_dump so it seems a bit
> arbitrary to kill its support for 7.3 specifically.

So we need to maintain V2 protocol in libpq to specifically support 7.3?

What's so special about 7.3?

> As near as I can tell the argument here is basically that we don't want
> to try to fix unfixable bugs in the V2-protocol code.  Well, yeah,
> they're unfixable ... why do you think we invented V3?  But they are
> what they are, and as long as you don't run into those limitations the
> protocol does still work.  There are plenty of features that require V3
> already, so I see no reason not to classify the row-processor stuff as
> one more.

Agreed.  But still - having to reorg the never-used V2 code in parallel
to actual development in V3 code makes all changes in the area
unnecessary harder.  

-- 
marko