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
signature.asc
Description:
On 2/16/24 02:35, shihao zhong wrote:
> On Tue, Feb 13, 2024 at 7:08 PM Michael Paquier 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, th
On Tue, Feb 13, 2024 at 7:08 PM Michael Paquier 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_by
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 s
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 propose
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
