Re: Binary support for pgoutput plugin
От | Andres Freund |
---|---|
Тема | Re: Binary support for pgoutput plugin |
Дата | |
Msg-id | 20190607232744.kn7vm6j7rqgune25@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Binary support for pgoutput plugin (Dave Cramer <davecramer@gmail.com>) |
Ответы |
Re: Binary support for pgoutput plugin
|
Список | 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 по дате отправления: