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?
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.
regards, tom lane
