Dag Lem writes:
> I sincerely hope this resolves any blocking issues with copyright /
> legalese / credits.
>
Can this now be considered ready for commiter, so that Paul or someone
else can flip the bit?
Best regards
Dag Lem
Dag Lem writes:
> Tomas Vondra writes:
>
>> On 2/7/23 18:08, Paul Ramsey wrote:
>>>
>>>
>>>> On Feb 7, 2023, at 6:47 AM, Dag Lem wrote:
>>>>
>>>> I just went by to check the status of the patch, and I noticed that
>>>
I sincerely hope this resolves any blocking issues with copyright /
legalese / credits.
Best regards
Dag Lem
diff --git a/contrib/fuzzystrmatch/Makefile b/contrib/fuzzystrmatch/Makefile
index 0704894f88..12baf2d884 100644
--- a/contrib/fuzzystrmatch/Makefile
+++ b/contrib/fuzzystrmatch/Makefile
Tomas Vondra writes:
> On 2/8/23 15:31, Dag Lem wrote:
>> Alvaro Herrera writes:
>>
>>> On 2023-Jan-17, Dag Lem wrote:
>>>
>>>> + * Daitch-Mokotoff Soundex
>>>> + *
>>>> + * Copyright (c) 2021 Finance Norway
>>&
Alvaro Herrera writes:
> On 2023-Jan-17, Dag Lem wrote:
>
>> + * Daitch-Mokotoff Soundex
>> + *
>> + * Copyright (c) 2021 Finance Norway
>> + * Author: Dag Lem
>
> Hmm, I don't think we accept copyright lines that aren't "PostgreSQL
> G
Tomas Vondra writes:
> On 2/7/23 18:08, Paul Ramsey wrote:
>>
>>
>>> On Feb 7, 2023, at 6:47 AM, Dag Lem wrote:
>>>
>>> I just went by to check the status of the patch, and I noticed that
>>> you've added yourself as reviewer earlier - great
Hi Paul,
I just went by to check the status of the patch, and I noticed that
you've added yourself as reviewer earlier - great!
Please tell me if there is anything I can do to help bring this across
the finish line.
Best regards,
Dag Lem
Alvaro Herrera writes:
> On 2023-Jan-05, Dag Lem wrote:
>
>> Is there anything else I should do here, to avoid the status being
>> incorrectly stuck at "Waiting for Author" again.
>
> Just mark it Needs Review for now. I'll be back from vacation
Paul Ramsey writes:
>> On Jan 12, 2023, at 7:30 AM, Dag Lem wrote:
>>
[...]
>>
>> Sure, I can do that. You don't think this much example text will be
>> TL;DR?
>
> I can only speak for myself, but examples are the meat of
> documentation learni
Paul Ramsey writes:
> On Mon, Jan 2, 2023 at 2:03 PM Dag Lem wrote:
>
>> I also improved on the documentation example (using Full Text Search).
>> AFAIK you can't make general queries like that using arrays, however in
>> any case I must admit that text arrays seem li
Alvaro Herrera writes:
> On 2023-Jan-05, Dag Lem wrote:
>
>> Is there anything else I should do here, to avoid the status being
>> incorrectly stuck at "Waiting for Author" again.
>
> Just mark it Needs Review for now. I'll be back from vacation
Is there anything else I should do here, to avoid the status being
incorrectly stuck at "Waiting for Author" again.
Best regards
Dag Lem
Sorry about the latest unfinished email - don't know what key
combination I managed to hit there.
Alvaro Herrera writes:
> Hello
>
> On 2022-Dec-23, Dag Lem wrote:
>
[...]
>
> So, yes, I'm proposing that we returns those as array elements and that
> @> is used t
Alvaro Herrera writes:
> Hello
>
> On 2022-Dec-23, Dag Lem wrote:
>
[...]
> So, yes, I'm proposing that we returns those as array elements and that
> @> is used to match them.
Looking into the array operators I guess that to match such arrays
directly one would actu
Dag Lem writes:
> Alvaro Herrera writes:
>
>> On 2022-Dec-23, Alvaro Herrera wrote:
>>
>
> [...]
>
>> I tried downloading a list of surnames from here
>> https://www.bibliotecadenombres.com/apellidos/apellidos-espanoles/
>> pasted that in a text f
o the same soundex code. I
fail to see how that is useful - if you want to find matches for a name,
you simply match against all indexed names. If you only consider one
sound, you won't find all names that match.
In any case, as explained in the documentation, the implementation is
intended to be a companion to Full Text Search, thus text is the natural
representation for the soundex codes.
BTW Vera 79 does not match Veras 794000, because they don't sound
the same (up to the maximum soundex code length).
Best regards
Dag Lem
ion produces documents
(words separated by space). As stated in the documentation: "Any
alternative soundex codes are separated by space, which makes the
returned text suited for use in Full Text Search".
Best regards,
Dag Lem
Tom Lane writes:
> Alvaro Herrera writes:
>> On 2022-Dec-22, Dag Lem wrote:
>>> This should hopefully fix the last Cfbot failures, by exclusion of
>>> daitch_mokotoff.h from headerscheck and cpluspluscheck.
>
>> Hmm, maybe it'd be better to move the typedef
Andres Freund writes:
> On 2022-12-22 14:27:54 +0100, Dag Lem wrote:
>> This should hopefully fix the last Cfbot failures, by exclusion of
>> daitch_mokotoff.h from headerscheck and cpluspluscheck.
>
> Btw, you can do the same tests as cfbot in your own repo by enabling
Dag Lem writes:
> Hi Ian,
>
> Ian Lawrence Barwick writes:
>
[...]
>> I see you provided some feedback on
>> https://commitfest.postgresql.org/36/3468/,
>> though the patch seems to have not been accepted (but not
>> conclusively rejected
>> eithe
Dag Lem writes:
> I noticed that the Meson builds failed in Cfbot, the updated patch adds
> a missing "include_directories" line to meson.build.
>
This should hopefully fix the last Cfbot failures, by exclusion of
daitch_mokotoff.h from headerscheck and cpluspluscheck.
Be
I noticed that the Meson builds failed in Cfbot, the updated patch adds
a missing "include_directories" line to meson.build.
Best regards
Dag Lem
diff --git a/contrib/fuzzystrmatch/Makefile b/contrib/fuzzystrmatch/Makefile
index 0704894f88..12baf2d884 100644
--- a/contrib/fuzzystrmatc
maximum octal number being 377).
Best regards
Dag Lem
The new status of this patch is: Waiting on Author
Hi Andreas,
Thank you for your detailed and constructive review!
I have made a conscientuous effort to address all the issues you point
out, please see comments below.
Andres Freund writes:
> Hi,
>
> On 2022-02-03 15:27:32 +0100, Dag Lem wrote:
[...]
> [23:43:34.796] contrib/f
Hi Ian,
Ian Lawrence Barwick writes:
> Hi Dag
>
> 2022年2月3日(木) 23:27 Dag Lem :
>>
>> Hi,
>>
>> Just some minor adjustments to the patch:
>>
>> * Removed call to locale-dependent toupper()
>> * Cleaned up input normalization
>
> This
only display the columns "Schema" and "Name" by default, and
use "+" to specify inclusion of the columns "Definition" and "Table".
Best regards
Dag Lem
for that.
Best regards
Dag Lem
diff --git a/contrib/fuzzystrmatch/Makefile b/contrib/fuzzystrmatch/Makefile
index 0704894f88..1d5bd84be8 100644
--- a/contrib/fuzzystrmatch/Makefile
+++ b/contrib/fuzzystrmatch/Makefile
@@ -3,14 +3,15 @@
MODULE_big = fuzzystrmatch
OBJS = \
$(WIN32RES
Dag Lem writes:
> Thomas Munro writes:
>
>> On Wed, Jan 5, 2022 at 2:49 AM Dag Lem wrote:
>>> However I guess this won't make any difference wrt. actually running the
>>> tests, as long as there seems to be an encoding problem in the cfbot
>>
>&g
Tom Lane writes:
> Dag Lem writes:
>
>> Running "ack -l '[\x80-\xff]'" in the contrib/ directory reveals that
>> two other modules are using UTF8 characters in tests - citext and
>> unaccent.
>
> Yeah, neither of those have been upgraded to said
Thomas Munro writes:
> On Wed, Jan 5, 2022 at 2:49 AM Dag Lem wrote:
>> However I guess this won't make any difference wrt. actually running the
>> tests, as long as there seems to be an encoding problem in the cfbot
>
> Fixed -- I told it to pull down patches as b
wrt. actually running the
tests, as long as there seems to be an encoding problem in the cfbot
pipeline.
Is there anything else I can do? Could perhaps fuzzystrmatch_utf8 simply
be commented out from the Makefile for the time being?
Best regards
Dag Lem
diff --git a/contrib/fuzzystrmatch/Make
ee that unaccent.sql starts as follows:
CREATE EXTENSION unaccent;
-- must have a UTF8 database
SELECT getdatabaseencoding();
SET client_encoding TO 'UTF8';
Would doing the same thing in fuzzystrmatch.sql fix the problem with
failing tests? Should I prepare a new patch?
Best regards
Dag Lem
is addition to the fuzzystrmatch extension module will prove
to be useful to others as well!
This is my very first code contribution to PostgreSQL, and I would be
grateful for any advice on how to proceed in order to get the patch
accepted.
Best regards
Dag Lem
diff --git a/contrib/fuzzystrmatc
']'); i += ilen)
> {
> }
>
> Say, a while loop or something?
The code gets to the next encodable character, skipping any other
characters. I have now added a comment which should hopefully make this
clearer, and broken up the for loop for readability.
Please find attached the revised
Please find attached an updated patch, with the following fixes:
* Replaced remaining malloc/free with palloc/pfree.
* Made "make check" pass.
* Updated notes on other implementations.
Best regards
Dag Lem
diff --git a/contrib/Makefile b/contrib/Makefile
index 87bf87ab90..5ea
of adjacent identical code
digits. Please see daitch_mokotoff.c for further references and
comments.
For reference, detailed instructions for soundex code comparison are
attached.
Best regards
Dag Lem
diff --git a/contrib/Makefile b/contrib/Makefile
index 87bf87ab90..5ea729 100644
36 matches
Mail list logo
