> 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