That sounds like a plausible approach. Have you done any performance
measurements?
No I haven't yet
In your patch, I would organize the changes to the portal API a bit
differently. Don't change the signature of CreatePortal().
okay
Get rid of PortalSetCurrentTop() and PortalClearCurrentTop().
I'll remove them from Portal API, but possibly have them in postgres.c
if you don't mind, just to avoid code duplication.
Renamed and maybe even inlined.
Just have a global
variable CurrentPortal and set it directly. And then change
GetCurrentPortalBindParameters() to take a Portal as argument. This can
all happen inside postgres.c without changing the Portal APIs.
Okay, will do
In fact, maybe don't use the Portal structure at all and just store the
saved textualized values inside postgres.c in a static variable.
Unlike SQL, parameters may spend much more memory, so I'd have them
in portal memory context to make sure the memory is released earlier
rather than later.
Tracking individual variable lifetime like we do with debug_query_string
sounds doable but a bit non-straightforward to me,
see e.g. the tricks we do with transaction commands.
Also, I'd like to avoid early forming of the error string, as we may
need to combine
them differently in future, e.g. when logging in various logging formats
or languages.
One-by-one pfree-ing doesn't look tempting either.
Do you think it would be acceptable to leave them cached in parameters
structure?
Best,
Alex
