Hey everyone,

I've been working with a couple people who didn't know that soundex and
metaphone were included in the distribution as contrib modules. While
it's their fault that they didn't check contrib, soundex is pretty
common among database systems and I was wondering if there was a reason
it is not included as a core function?

-Jonah

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

"Jonah H. Harris" <jharris@tvi.edu> writes:

> Hey everyone,
>
> I've been working with a couple people who didn't know that soundex
> and metaphone were included in the distribution as contrib modules.
> While it's their fault that they didn't check contrib, soundex is
> pretty common among database systems and I was wondering if there was
> a reason it is not included as a core function?

Because no one's taken ownership of the code and made a case for
integrating it into the core backend.

-Doug

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

At a minimum I think we should support soundex in the core. I'm willing
to move soundex and metaphone into the backend. Does anyone see a
reason not to do so?

Douglas McNaught wrote:

>"Jonah H. Harris" <jharris@tvi.edu> writes:
>
>
>
>>Hey everyone,
>>
>>I've been working with a couple people who didn't know that soundex
>>and metaphone were included in the distribution as contrib modules.
>>While it's their fault that they didn't check contrib, soundex is
>>pretty common among database systems and I was wondering if there was
>>a reason it is not included as a core function?
>>
>>
>
>Because no one's taken ownership of the code and made a case for
>integrating it into the core backend.
>
>-Doug
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
>


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Jonah H. Harris wrote:
> At a minimum I think we should support soundex in the core. I'm
> willing to move soundex and metaphone into the backend. Does anyone
> see a reason not to do so?

Soundex is really only useful for English names with English
pronunciation. If we were to adapt a phonetic algorithm into the core,
I'd like to see something more general.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Peter,

I don't disagree with you that a more generalized function would also be
good, just that soundex is common and would be helpful if it were built-in.

Peter Eisentraut wrote:

>Jonah H. Harris wrote:
>
>
>>At a minimum I think we should support soundex in the core. I'm
>>willing to move soundex and metaphone into the backend. Does anyone
>>see a reason not to do so?
>>
>>
>
>Soundex is really only useful for English names with English
>pronunciation. If we were to adapt a phonetic algorithm into the core,
>I'd like to see something more general.
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Jonah H. Harris wrote:

> At a minimum I think we should support soundex in the core. I'm
> willing to move soundex and metaphone into the backend. Does anyone
> see a reason not to do so?
>
>
I take it you mean apart from the fact that soundex is horribly limited
and out of data and probably nobody should be using it?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Tom Lane wrote:

>"Jonah H. Harris" <jharris@tvi.edu> writes:
>
>
>>At a minimum I think we should support soundex in the core. I'm willing
>>to move soundex and metaphone into the backend. Does anyone see a
>>reason not to do so?
>>
>>
>
>Is it really ready for prime time? For one thing, a quick look shows no
>evidence of being multibyte-ready. There's a fair amount of cleanup of
>random private coding conventions (META_MALLOC!?) to be done too.
>
>Doug's point is valid: there's some actual work needed here, not just
>arguing to shove the code from point A to point B.
>
>
>
>

Well, META_MALLOC occurs in part of the code that he didn't ask for ...
it was inherited from the perl module code that I adapted to do double
metaphone. And a minimal wrapper suited my purposes at the time just fine.

But the point is well taken nevertheless.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

"Jonah H. Harris" <jharris@tvi.edu> writes:
> At a minimum I think we should support soundex in the core. I'm willing
> to move soundex and metaphone into the backend. Does anyone see a
> reason not to do so?

Is it really ready for prime time? For one thing, a quick look shows no
evidence of being multibyte-ready. There's a fair amount of cleanup of
random private coding conventions (META_MALLOC!?) to be done too.

Doug's point is valid: there's some actual work needed here, not just
arguing to shove the code from point A to point B.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Jonah H. Harris wrote:
> I'm willing to move soundex and metaphone into the backend.
> Does anyone see a reason not to do so?

As a kinda strange reason, I like them in contrib because
they demonstrate a nice simple example of how one can write a
contrib extension.

This module has simple functions that take a string or
two and return a string or number. Most of the other
contrib modules do tricky stuff with weird types or
indexes that make them rather complex to use as
a starting point.

If they were to be moved out of contrib, I think it'd be
really nice if someone add a "hello_world" contrib that
demonstrates a bunch of simple operations in C to be used
as such a model.