Thread: email built in type
Hi all, about you is it ok for you if I write the email built in type ? I know of course that I can do it with a DOMAIN. Regards Gaetano Mendola
Gaetano Mendola <mendola@bigfoot.com> writes:
> about you is it ok for you if I write the email built in type ?
You're going to have to explain why it has to be a built-in type.
Can't you do what you want as a local add-on? Is it likely that
the functionality you have in mind would be exactly what anyone
else would want?
regards, tom lane
Tom Lane wrote: > Gaetano Mendola <mendola@bigfoot.com> writes: > >>about you is it ok for you if I write the email built in type ? > > > You're going to have to explain why it has to be a built-in type. > Can't you do what you want as a local add-on? Is it likely that > the functionality you have in mind would be exactly what anyone > else would want? 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, considering also that I wish select email for domain like: select * from users where email >> 'hotmail.com'; About the functionality we can have a deal on which functionality this type should have. I'll do it also in order to acquire confidence with the pg code. Regards Gaetano Mendola
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.
> 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.
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).
regards, tom lane
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
--On Samstag, Mai 08, 2004 14:14:10 +0200 Gaetano Mendola <mendola@bigfoot.com> wrote: > Hi all, > about you is it ok for you if I write the email built in type ? > > I know of course that I can do it with a DOMAIN. > > Regards > Gaetano Mendola Funny, I had the idea some time ago, too. The problem was that I needed some fast and easy-to-use interface to manage much email adresses for a e-marketing system. Because i've run out of time, i decided to do syntax stuff on the application side (the regexp for validation isn't really complicated...) and queries with some kind of "access functions" like get_domain, get_alias. If you put a functional index on them the queries are fast and efficient. Query all email adresses for a specific characteristic with such functions isn't complicated, you can do that even with SUBSTRING in simple SQL-functions and i can't really see the advantage of a '>>' operator against a get_domain() function (regarded to usability) now. Anyways, perhaps this is something for pgfoundry? -- Bernd
On Sat, 2004-05-08 at 13:10, Gaetano Mendola wrote: > However an *add on* is an *add on* with not the same eligibility > of the main project I'd suggest implementing the custom datatype first and packaging it separately (say, via pgFoundry) -- it can always be moved into the core distribution at some later point, if and when it has been proven stable and is in wide use. (I'm not sure that those conditions will ever be met, mind you -- but arguing for its inclusion in the main sources prior to even having begun implementing it is unlikely to convince anybody.) -Neil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Conway wrote: | On Sat, 2004-05-08 at 13:10, Gaetano Mendola wrote: | |>However an *add on* is an *add on* with not the same eligibility |>of the main project | | | I'd suggest implementing the custom datatype first and packaging it | separately (say, via pgFoundry) -- it can always be moved into the core | distribution at some later point, if and when it has been proven stable | and is in wide use. I finish just now to create the project on pgfoundry I hope it will be accepted. Regards Gaetano Mendola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAoA+b7UpzwH2SGd4RAhksAJ99HS549e5VrpvdSIRex0axSgeeQwCgy3yJ 0153kB1mRqdQYMS3sY6hOko= =f17C -----END PGP SIGNATURE-----