Policy on contrib has shifted over time. But generally we want to encourage a lively ecosystem of extensions maintained outside of the Postgres source tree so we avoid adding things to contrib when there's no particular advantage.
The most common reason things are added to contrib is when the extension is closely tied to internals and needs to be maintained along with changes to internals. Modules like that are hard to maintain separately. But modules that use documented general extensibility APIs should be able to be stable across versions and live outside contrib.
On Thu 3 Jan 2019, 23:54 Daniel Heath <daniel@heath.cc wrote:
Would this also be appropriate for inclusion as contrib? I'm unfamiliar with the policy for what is / is not included there.
Thanks,
Daniel Heath
On Fri, Jan 4, 2019, at 9:47 AM, Fabrízio de Royes Mello wrote:
Em qui, 3 de jan de 2019 às 20:22, Daniel Heath <daniel@heath.cc> escreveu:
Hi All,
I've frequently seen an issue in applications which store titles (eg of books, events, user profiles) where duplicate values are not properly vetted.
The 'citext' type is helpful here, but I'd be keen to go further.
I propose a 'titletext' type, which has the following properties when compared for equality:
* Case insensitivity (like 'citext')
* Only considers characters in [:alnum:] (that is, ignores spaces, punctuation, etc)
This would be useful for a range of situations where it's important to avoid entering duplicate values.
