delta/postgresql.git/contrib/fuzzystrmatch, branch master git.postgresql.org: git/postgresql.git Ensure Soundex difference() function handles empty input sanely. 2023-05-16T14:53:42+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-05-16T14:53:42+00:00 1d369c9e90f311ec98b07a259cac48c404c773d5 fuzzystrmatch's difference() function assumes that _soundex() always initializes its output buffer fully. This was not so for the case of a string containing no alphabetic characters, resulting in unstable output and Valgrind complaints. Fix by using memset() to fill the whole buffer in the early-exit case. Also make some cosmetic improvements (I didn't care for the random switches between "instr[0]" and "*instr" notation). Report and diagnosis by Alexander Lakhin (bug #17935). Back-patch to all supported branches. Discussion: https://postgr.es/m/17935-b99316aa79c18513@postgresql.org 
fuzzystrmatch's difference() function assumes that _soundex()
always initializes its output buffer fully.  This was not so for
the case of a string containing no alphabetic characters, resulting
in unstable output and Valgrind complaints.

Fix by using memset() to fill the whole buffer in the early-exit
case.  Also make some cosmetic improvements (I didn't care for the
random switches between "instr[0]" and "*instr" notation).

Report and diagnosis by Alexander Lakhin (bug #17935).
Back-patch to all supported branches.

Discussion: https://postgr.es/m/17935-b99316aa79c18513@postgresql.org
Avoid using non-ASCII commentary in daitch_mokotoff.c. 2023-04-16T16:57:32+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-04-16T16:57:32+00:00 1c54b93a8cf959a826dfabd6cae55dce255df2f5 Commit d6b5dee42 failed to suppress that warning from MSVC, so let's just get rid of all non-ASCII glyphs in the comments. The comment for iso8859_1_to_ascii_upper[] is not essential, and the other cases can be handled by spelling out the Unicode character names. (I'm now really in the dark as to why MSVC doesn't complain about predicate.c's comment. But whatever.) Discussion: https://postgr.es/m/1546512.1681495035@sss.pgh.pa.us 
Commit d6b5dee42 failed to suppress that warning from MSVC,
so let's just get rid of all non-ASCII glyphs in the comments.
The comment for iso8859_1_to_ascii_upper[] is not essential,
and the other cases can be handled by spelling out the
Unicode character names.

(I'm now really in the dark as to why MSVC doesn't complain
about predicate.c's comment.  But whatever.)

Discussion: https://postgr.es/m/1546512.1681495035@sss.pgh.pa.us
Remove some non-ASCII symbols from a comment. 2023-04-15T15:20:46+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-04-15T15:20:46+00:00 d6b5dee42de71f547090f0cd2968112c50c24203 Buildfarm member hamerkop is unhappy that daitch_mokotoff.c "contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss". There are a lot of non-ASCII characters in comments, but I do not see any outside a comment, so this is just cosmetic. Nonetheless the warning is fairly scary and people might waste time trying to understand the cause, so we ought to silence it. We have only one other occurrence of a non-ASCII character in .c or .h files in the tree: predicate.c mentions "Uwe Röhm". It's far from clear why hamerkop isn't complaining about that too; but it isn't, so maybe there is some special provision for accented Roman letters. We can remove the non-letter symbols from the comment for iso8859_1_to_ascii_upper without any real loss of usefulness, so let's try that first to see if it silences the warning. Discussion: https://postgr.es/m/1546512.1681495035@sss.pgh.pa.us 
Buildfarm member hamerkop is unhappy that daitch_mokotoff.c "contains
a character that cannot be represented in the current code page
(932). Save the file in Unicode format to prevent data loss".  There
are a lot of non-ASCII characters in comments, but I do not see any
outside a comment, so this is just cosmetic.  Nonetheless the warning
is fairly scary and people might waste time trying to understand the
cause, so we ought to silence it.

We have only one other occurrence of a non-ASCII character in .c or .h
files in the tree: predicate.c mentions "Uwe Röhm".  It's far from
clear why hamerkop isn't complaining about that too; but it isn't,
so maybe there is some special provision for accented Roman letters.
We can remove the non-letter symbols from the comment for
iso8859_1_to_ascii_upper without any real loss of usefulness,
so let's try that first to see if it silences the warning.

Discussion: https://postgr.es/m/1546512.1681495035@sss.pgh.pa.us
Remove useless dependencies in daitch_mokotoff_header.pl. 2023-04-08T03:23:25+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-04-08T03:22:28+00:00 2bfbad9c42207b4ba75cfce9901fa78f2c024b61 Actually, the correct fix for this is "we don't need this at all", because this program isn't dealing in any non-ASCII data. The dependency on Data::Dumper seems to be a leftover too. Discussion: https://postgr.es/m/3287943.1680922997@sss.pgh.pa.us 
Actually, the correct fix for this is "we don't need this at all",
because this program isn't dealing in any non-ASCII data.  The
dependency on Data::Dumper seems to be a leftover too.

Discussion: https://postgr.es/m/3287943.1680922997@sss.pgh.pa.us
Pacify perlcritic. 2023-04-08T01:33:05+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-04-08T01:32:44+00:00 edc627ae27632ae2be0e435aca02ed38005cb55f Discussion: https://postgr.es/m/3271512.1680916423@sss.pgh.pa.us 
Discussion: https://postgr.es/m/3271512.1680916423@sss.pgh.pa.us
Add support for Daitch-Mokotoff Soundex in contrib/fuzzystrmatch. 2023-04-07T21:32:26+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-04-07T21:31:51+00:00 a290378a3752f787cdc2252889ba513f6fb393db This modernized version of Soundex works significantly better than the original, particularly for non-English names. Dag Lem, reviewed by quite a few people along the way Discussion: https://postgr.es/m/yger1atbgfy.fsf@sid.nimrod.no 
This modernized version of Soundex works significantly better than
the original, particularly for non-English names.

Dag Lem, reviewed by quite a few people along the way

Discussion: https://postgr.es/m/yger1atbgfy.fsf@sid.nimrod.no
New header varatt.h split off from postgres.h 2023-01-10T04:54:36+00:00 Peter Eisentraut peter@eisentraut.org 2023-01-10T04:48:59+00:00 d952373a987bad331c0e499463159dd142ced1ef This new header contains all the variable-length data types support (TOAST support) from postgres.h, which isn't needed by large parts of the backend code. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/ddcce239-0f29-6e62-4b47-1f8ca742addf%40enterprisedb.com 
This new header contains all the variable-length data types support
(TOAST support) from postgres.h, which isn't needed by large parts of
the backend code.

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/ddcce239-0f29-6e62-4b47-1f8ca742addf%40enterprisedb.com
Update copyright for 2023 2023-01-02T20:00:37+00:00 Bruce Momjian bruce@momjian.us 2023-01-02T20:00:37+00:00 c8e1ba736b2b9e8c98d37a5b77c4ed31baf94147 Backpatch-through: 11 
Backpatch-through: 11
Add copyright notices to meson files 2022-12-20T12:54:39+00:00 Andrew Dunstan andrew@dunslane.net 2022-12-20T12:54:39+00:00 8284cf5f746f84303eda34d213e89c8439a83a42 Discussion: https://postgr.es/m/222b43a5-2fb3-2c1b-9cd0-375d376c8246@dunslane.net 
Discussion: https://postgr.es/m/222b43a5-2fb3-2c1b-9cd0-375d376c8246@dunslane.net
Remove AssertArg and AssertState 2022-10-28T07:19:06+00:00 Peter Eisentraut peter@eisentraut.org 2022-10-28T07:19:06+00:00 b1099eca8f38ff5cfaf0901bb91cb6a22f909bc6 These don't offer anything over plain Assert, and their usage had already been declared obsolescent. Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/20221009210148.GA900071@nathanxps13 
These don't offer anything over plain Assert, and their usage had
already been declared obsolescent.

Author: Nathan Bossart <nathandbossart@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/20221009210148.GA900071@nathanxps13