Thread: Fix incorrect PG_GETARG in pgcrypto
Hi hackers, I'd like to bring to your attention that I recently identified some functions in pgcrypto that are using PG_GETARG functions in a way that doesn't match the expected function signature of the stored procedures. This patch proposes a solution to address these inconsistencies and ensure proper alignment. Thanks, Shihao
Attachment
On Mon, Feb 12, 2024 at 11:30:40PM -0500, shihao zhong wrote: > I'd like to bring to your attention that I recently identified some > functions in pgcrypto that are using PG_GETARG functions in a way that > doesn't match the expected function signature of the stored > procedures. This patch proposes a solution to address these > inconsistencies and ensure proper alignment. You've indeed grabbed some historical inconsistencies here. Please note that your patch has reversed diffs (for example, the SQL definition of pgp_sym_encrypt_bytea uses bytea,text,text as arguments and your resulting patch shows how HEAD does the job with bytea,bytea,bytea), but perhaps you have generated it with a command like `git diff -R`? -- Michael
Attachment
On Tue, Feb 13, 2024 at 05:36:36PM +0900, Michael Paquier wrote: > You've indeed grabbed some historical inconsistencies here. Please > note that your patch has reversed diffs (for example, the SQL > definition of pgp_sym_encrypt_bytea uses bytea,text,text as arguments > and your resulting patch shows how HEAD does the job with > bytea,bytea,bytea), but perhaps you have generated it with a command > like `git diff -R`? The reversed part of the patch put aside aside, I've double-checked your patch and the inconsistencies seem to be all addressed in this area. The symmetry that we have now between the bytea and text versions of the functions is stunning, but I cannot really get excited about merging all of them either as it would imply a bump of pgcrypto to update the prosrc of these functions, and we have to maintain runtime compatibility with older versions. -- Michael
Attachment
On Tue, Feb 13, 2024 at 7:08 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Feb 13, 2024 at 05:36:36PM +0900, Michael Paquier wrote: > > You've indeed grabbed some historical inconsistencies here. Please > > note that your patch has reversed diffs (for example, the SQL > > definition of pgp_sym_encrypt_bytea uses bytea,text,text as arguments > > and your resulting patch shows how HEAD does the job with > > bytea,bytea,bytea), but perhaps you have generated it with a command > > like `git diff -R`? > > The reversed part of the patch put aside aside, I've double-checked > your patch and the inconsistencies seem to be all addressed in this > area. Thanks for fixing and merging this patch, I appreciate it! Thanks, Shihao > The symmetry that we have now between the bytea and text versions of > the functions is stunning, but I cannot really get excited about > merging all of them either as it would imply a bump of pgcrypto to > update the prosrc of these functions, and we have to maintain runtime > compatibility with older versions. > -- > Michael
On 2/16/24 02:35, shihao zhong wrote: > On Tue, Feb 13, 2024 at 7:08 PM Michael Paquier <michael@paquier.xyz> wrote: >> >> On Tue, Feb 13, 2024 at 05:36:36PM +0900, Michael Paquier wrote: >>> You've indeed grabbed some historical inconsistencies here. Please >>> note that your patch has reversed diffs (for example, the SQL >>> definition of pgp_sym_encrypt_bytea uses bytea,text,text as arguments >>> and your resulting patch shows how HEAD does the job with >>> bytea,bytea,bytea), but perhaps you have generated it with a command >>> like `git diff -R`? >> >> The reversed part of the patch put aside aside, I've double-checked >> your patch and the inconsistencies seem to be all addressed in this >> area. > Thanks for fixing and merging this patch, I appreciate it! > Should this be marked as committed, or is there some remaining part? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Feb 26, 2024 at 02:47:27PM +0100, Tomas Vondra wrote: > Should this be marked as committed, or is there some remaining part? Thanks. I've missed the existence of [1]. It is now marked as committed. [1]: https://commitfest.postgresql.org/47/4822/ -- Michael