Re: Domains and supporting functions - Mailing list pgsql-hackers

From elein
Subject Re: Domains and supporting functions
Date
Msg-id 20060220034831.GP15582@varlena.com
Whole thread Raw
In response to Re: Domains and supporting functions  (elein <elein@varlena.com>)
List pgsql-hackers
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@varlena.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@varlena.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
uniqueindex 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@varlena.com
I've always depended on the [QA] of strangers. :)



pgsql-hackers by date:

Previous
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: Pgfoundry and gborg: shut one down
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Pgfoundry and gborg: shut one down