On Fri, 21 Mar 2025 13:45:24 -0700
Jeff Davis <pgsql@j-davis.com> wrote:
> > Maybe we should actually move in the direction of having encodings
> > that are essentially specific versions of Unicode. Instead of just
> > having UTF-8 that accepts whatever, you could have UTF-8.v16.0.0 or
> > whatever, which would only accept code points known to that version
> > of
> > Unicode. Or maybe this shouldn't be entirely new encodings but
> > something vaguely akin to a typmod, so that you could have columns
> > of type text[limited_to_unicode_v16_0_0] or whatever. If we actually
> > exclude unassigned code points, then we know they aren't there, and
> > we
> > can make deductions about what is safe to do based on that
> > information.
>
> I like this line of thinking, vaguely similar to my STRICT_UNICODE
> database option proposal. Maybe these aren't exactly the right things
> to do, but I think there are some possibilities here, and we shouldn't
> give up and assume there's a problem when usually there is not.
There is "the iPhone paradox" here; if we reject unassigned code
points, then websites are going to start throwing database errors for
anyone with the latest iPhone who uses a new emoji.
(Unless the database is updated very quickly, which is atypical.) Apple
tends to get new emojis into consumers hands a year or less after the
new Unicode release.
-Jeremy
