Re: Domains and supporting functions

On Sun, Feb 19, 2006 at 10:34:02AM -0800, elein wrote:
> On Sun, Feb 19, 2006 at 01:26:31AM -0500, Tom Lane wrote:
> > elein <elein(at)varlena(dot)com> writes:
> > > I've got a domain based on a text type.
> > > I've overridden the equal operator with
> > > lower(text) = lower(text).
> >
> > This won't work, you need to make a type instead.
> >
>
> Actually I can do and have done this. It is being tested now.
> I did create an opclass. It creates a UNIQUE index just fine
> for the type using the lower() functionality. *If* it passes
> all of my testing I'll publish it tomorrow on general bits.
> Perhaps folks can help try to break it when I publish (or
> if you are around today Sunday, you can test in advance--email me
> directly.)
>
> If it doesn't pass the tests, well, I'm hoping
> it will be functionally close enough for common use. This
> implementation is all in SQL and plperl--no C code.
>
> Now my only complaint is that ORDER BY requires the USING op
> when it should recognize the information in the opclass for
> btree > and < for the type of the sort column. I can explain
> why it doesn't recognize the opclass information, but I think
> it should.
>
>
> > > If this is the way domains really are, I would strongly suggest
> > > expanding create domain to merge with create type (under) and
> > > allow us to list the basic functions.
> >
> > IMHO, the exact difference between a domain and a type is you get to
> > choose your own definitions of the basic operations on a type. There's
> > no free lunch: as soon as you start substituting operations the
> > complexity involved goes up by an order of magnitude.
>
> Type inheritance for base types should work by inheriting all of the
> parent's definitions and overriding them only as necessary. What I'm
> trying to do is to demonstrate that we can weasle this functionality
> using domains.
>
> --elein
> elein(at)varlena(dot)com
>
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >

OK. My article (and code) is published. It could probably use some more tries to
find holes in the implementation.

http://www.varlena.com/GeneralBits/128.php

Known Problems and Issues:

* Creating the table with an email PRIMARY KEY did not use our comparison function. It was necessary to create a unique index which explicitly used the email operator class.
* ORDER BY requires USING op clause.
* LIKE does not work. Use defined operator % instead.

There are convincing arguments for and against this behavior. Feel free to argue one way or the other.

eleie(at)varlena(dot)com
I've always depended on the [QA] of strangers. :)