Re: email built in type - Mailing list pgsql-hackers

From Gaetano Mendola
Subject Re: email built in type
Date
Msg-id 409D1497.90205@bigfoot.com
Whole thread Raw
In response to Re: email built in type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: email built in type  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Tom Lane wrote:

> Gaetano Mendola <mendola@bigfoot.com> writes:
> 
>>Tom Lane wrote:
>>
>>>Can't you do what you want as a local add-on?
> 
> 
>>I guess that for manage efficiently million of email addresses I need
>>to have a built in type instead of a domain with a regex as validator,
> 
> 
> You probably ought to do some measurements before assuming that.

I will do it with the inet data type.

>>considering also that I wish select email for domain like:
>>select * from users where email >> 'hotmail.com';
> 
> 
> I don't think you need write a line of C code for that either;
> a functional index would do the job.

I will do same sort of benchmarking using the inet data type.


> But even if you want to do it as a custom datatype, it can be an
> *add on*.  Postgres is designed for extension in-the-field and
> I see nothing here that requires the type to be built in.  See all
> the examples in contrib (I think there are some on gborg as well).

Do you mean writing my DOMAIN type ?

Why then inet, macaddress are built in data type?

However an *add on* is an *add on* with not the same eligibility
of the main project, see for example the reticency to use it
because you have to specify more instruction for the "operation"
department, this is sad but true; see the comparison between
Postgres and MySQL about the support for transaction: Postgres have
it native, MySQL yes ( some one still write *no* ) *but* using
external module;



Regards
Gaetano Mendola




















pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Comments on all system objects
Next
From: Bruce Momjian
Date:
Subject: Relocatable installs