Re: Raising the SCRAM iteration count - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Raising the SCRAM iteration count
Date
Msg-id 43717B6D-9227-4561-9255-A0F2EF612AAA@yesql.se
Whole thread Raw
In response to Re: Raising the SCRAM iteration count  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Raising the SCRAM iteration count  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> On 27 Feb 2023, at 08:06, Michael Paquier <michael@paquier.xyz> wrote:

> +       conn->scram_sha_256_iterations = atoi(value);
> +   }
> This should match on "scram_iterations", which is the name of the
> GUC.

Fixed.

> Would the long-term plan be to use multiple variables in conn if
> we ever get to <method>:<iterations> that would require more parsing?

I personally don't think we'll see more than 2 or at most 3 values so parsing
that format shouldn't be a problem, but it can always be revisited if/when we
get there.

> Perhaps there should be a test with \password to make sure that libpq
> gets the call when the GUC is updated by a SET command?

That would indeed be nice, but is there a way to do this without a complicated
pump TAP expression?  I was unable to think of a way but I might be missing
something?

--
Daniel Gustafsson


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Making empty Bitmapsets always be NULL
Next
From: Jelte Fennema
Date:
Subject: Re: running logical replication as the subscription owner