From: | Mat Arye <mat(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Question about toasting code |
Date: | 2017-05-07 17:04:12 |
Message-ID: | CADsUR0B=jVvXtPpFr9kXS6EH8duHzXAwBzg7CLxJW=ycJciFqA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I am trying to create a custom aggregate and have run across some puzzling
code while trying to figure out how to implement it.
This is in arrayfuncs.c:5022 (postgre 9.6.2)
/*
* Ensure pass-by-ref stuff is copied into mcontext; and detoast it too if
* it's varlena. (You might think that detoasting is not needed here
* because construct_md_array can detoast the array elements later.
* However, we must not let construct_md_array modify the ArrayBuildState
* because that would mean array_agg_finalfn damages its input, which is
* verboten. Also, this way frequently saves one copying step.)
*/
if (!disnull && !astate->typbyval)
{
if (astate->typlen == -1)
dvalue = PointerGetDatum(PG_DETOAST_DATUM_COPY(dvalue));
else
dvalue = datumCopy(dvalue, astate->typbyval, astate->typlen);
}
I am a bit confused by the comment.
Does PG_DETOAST_DATUM_COPY(dvalue) modify dvalue? Shouldn't that not
modify the value (implied by _COPY)? If so then why does the detoasting
have to happen ahead of time and cannot happen at a later stage (in the
finalfunc or serializefunc etc.)? I understand that at those later stages
you cannot modify the input, but why would you have to in order to DETOAST?
The thing I am struggling with is with the serialize/deserialize functions.
Can I detoast inside the serialize function if I use _COPY? Or is there a
reason I have to detoast during the sfunc?
Thanks,
Mat
TimescaleDB
From | Date | Subject | |
---|---|---|---|
Next Message | Daniele Varrazzo | 2017-05-07 18:27:08 | Detecting schema changes during logical replication |
Previous Message | Robert Haas | 2017-05-07 15:54:48 | Re: statement_timeout is not working as expected with postgres_fdw |