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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > > > > 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. [EMAIL PROTECTED] I've always depended on the [QA] of strangers. :) ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
