Re: Binary support for pgoutput plugin - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Binary support for pgoutput plugin
Date
Msg-id 20190607232744.kn7vm6j7rqgune25@alap3.anarazel.de
Whole thread Raw
In response to Re: Binary support for pgoutput plugin  (Dave Cramer <davecramer@gmail.com>)
Responses Re: Binary support for pgoutput plugin
List pgsql-hackers
Hi,

On 2019-06-05 19:05:05 -0400, Dave Cramer wrote:
> I am curious why you are "strongly" opposed however. We already have the
> information. Adding doesn't seem onerous.

(thought I'd already replied with this)

The problem is that I don't recognize a limiting principle:

If we want NOT NULL information for clients, why don't we include the
underlying types for arrays, and the fields in composite types? What
about foreign keys? And unique keys?

And then we suddenly need tracking for all these, so we don't always
send out that information when we previously already did - and in some
of the cases there's no infrastructure for that.

I just don't quite buy that the output plugin build for pg's logical
replication needs is a good place to include a continually increasing
amount of metadata that logical replication doesn't need.  That's going
to add overhead and make the code more complicated.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Temp table handling after anti-wraparound shutdown (Was: BUG #15840)
Next
From: Michael Paquier
Date:
Subject: Re: Temp table handling after anti-wraparound shutdown (Was: BUG#15840)