On Tue, Feb 27, 2018 at 2:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> +1. We don't have to support everything, but things that don't work
>> should fail on insertion, not retrieval. Otherwise what we have is
>> less a database and more a data black hole.
>
> That sounds nice as a principle but I'm not sure how workable it really
> is. Do you want to reject text strings that fit fine in, say, LATIN1
> encoding, but might be overlength if some client tries to read them in
> UTF8 encoding? (bytea would have a comparable problem with escape vs hex
> representation, for instance.) Should the limit vary depending on how
> many columns are in the table? Should we account for client-side tuple
> length restrictions?
I suppose what I really want is to have a limit that's large enough
for how big the retrieved data can be that people stop hitting it.
> Anyway, as Alvaro pointed out upthread, we've been down this particular
> path before and it didn't work out. We need to learn something from that
> failure and decide how to move forward.
Yep.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company