06.12.2024 21:04, Matthias van de Meent:
On Thu, 5 Dec 2024 at 15:02, Alexander Borisov <lex.bori...@gmail.com> wrote:
[..]
I'd be extremely annoyed if URLs I wrote into the database didn't return in identical manner when fetched from the database. See also how numeric has different representations of the same value: 2.0 and 2.00 are equivalent for sorting purposes, they aren't the same and cannot just truncate those zeroes. Note that a path of "/%2e/" could well be interpreted differently from "/./" or "/" by a server.
That's why data types are invented. Most likely, you will not be able to write bad UTF-8 bit sequence into a field with the text type. Because the incoming data will not pass validation. The user chooses the data type for his needs, knowing how it works. I mean that the data in the database should be stored validated and choosing the URL type to store URLs should not be surprised that the incoming URL will be parsed and will pass validation. Also, no one is stopping you from storing the URL in text format and using the new type on the fly.
I don't think choosing to defer to a living standard is a good idea for contrib extensions, which are expected to be supported and stable with the major PostgreSQL release they're bundled with. If (when) that living standard gets updated, as tends to happen to such standards, we'd suddenly lose compatibility with the standard we said we supported, which isn't a nice outlook. Compare that to RFCs, which AFAIK don't change in specification once released.
WHATWG: "The standard can generally not be changed in backwards-incompatible ways without extreme care, and with implementer commitments leading the way." You can read more about what it means Living Standard https://whatwg.org/faq#living-standard. -- Alexander Borisov
