On Wed, Sep 25, 2024 at 12:10:02PM +0900, Michael Paquier wrote:
> The remaining 0002 is attached for now. I am planning to wrap that
> next week after a second lookup, except if there are any comments, of
> course.
And done with that, after a second round, tweaking some comments.
Thanks Greg fo
On Tue, Sep 24, 2024 at 04:57:28PM +0900, Michael Paquier wrote:
> 0001 is straight-forward and that was I think a mistake to not include
> that from the start when I've expanded these tests in the v16 cycle
> (well, time..). 0002 also is quite conservative at the end, and this
> design can be use
On Mon, Aug 19, 2024 at 03:28:52PM +0900, Michael Paquier wrote:
> FWIW, I'm OK with hiding the value when it comes to a SET clause in a
> CREATE FUNCTION. We already hide the contents of SQL queries inside
> the SQL functions when these are queries that can be normalized, so
> there is a kind of
On Tue, Aug 13, 2024 at 10:54:34AM -0400, Greg Sabino Mullane wrote:
> Now that I've spent some time away from this, I'm reconsidering why we are
> going through all the trouble of semi-jumbling SET statements. Maybe we
> just keep it simple and everything becomes "SET myvar = $1" or even "SET
> my
Now that I've spent some time away from this, I'm reconsidering why we are
going through all the trouble of semi-jumbling SET statements. Maybe we
just keep it simple and everything becomes "SET myvar = $1" or even "SET
myvar" full stop? I'm having a hard time finding a real-world situation in
whic
On Mon, Jul 22, 2024 at 03:23:50PM -0400, Greg Sabino Mullane wrote:
> I saw a database recently where some app was inserting the source port into
> the application_name field, which meant that pg_stat_statements.max was
> quickly reached and queries were simply pouring in and out of
> pg_stat_stat
