On Thu, 5 Dec 2024 at 15:02, Alexander Borisov <lex.borisov@gmail.com> wrote:
> What is the main difference between WHATWG and RFC 3986?
[snip]
> [host]
> Source: https://exаmple.com/ (а — U+0430)
> RFC 3986: https://exаmple.com/.
> WHATWG: https://xn--exmple-4nf.com/.
[snip]
> [path]
> Source: https://example.com/a/./b/../c
> RFC 3986: https://example.com/a/./b/../c.
> WHATWG: https://example.com/a/c.
[snip]
> Proposal
>
> I propose to add a new data type for PostgreSQL as an extension, in
> contrib. Name the new type URL and use the WHATWG URL specification to
> implement the new type.
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.
> The choice of URL parsing specification is
> justified by the following factors:
> 1. Live specification, adopts to modern realities.
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.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
