Hi,
Thanks for "fixing" this so quickly.
Greetings,
Andres Freund
On Mon, Oct 17, 2022 at 10:13:33AM +0900, Michael Paquier wrote:
> That's just assign_record_type_typmod(), which would make sure to fill
> the cache for a RECORD tupdesc. How about "fill the cache with the
> information of the tuple descriptor type, for a transient RECORD
> datatype"? If you hav
On Sun, Oct 16, 2022 at 03:09:14PM -0700, Andres Freund wrote:
> On 2022-10-15 11:41:08 +0900, Michael Paquier wrote:
>> -/* flag bits for SetSingleFuncCall() */
>> -#define SRF_SINGLE_USE_EXPECTED 0x01/* use expectedDesc as tupdesc
>> */
>> -#define SRF_SINGLE_BLESS0x02/*
On Sun, Oct 16, 2022 at 03:04:43PM -0700, Andres Freund wrote:
> Yes - it'd introduce an ABI break, i.e. an already compiled extension
> referencing SetSingleFuncCall() wouldn't fail to load into an upgraded sever,
> due to the reference to the SetSingleFuncCall, which wouldn't exist anymore.
Note
Hi,
On 2022-10-15 11:41:08 +0900, Michael Paquier wrote:
> Attached is a patch for HEAD and REL_15_STABLE to switch this stuff with new
> names, with what's needed for ABI compatibility. My plan would be to keep
> the compatibility parts only in 15, and drop them from HEAD. -- Michael
Looks rea
Hi,
On 2022-10-16 13:22:41 -0700, Melanie Plageman wrote:
> On Fri, Oct 14, 2022 at 7:41 PM Michael Paquier wrote:
> - * SetSingleFuncCall
> + * Compatibility function for v15.
> + */
> +void
> +SetSingleFuncCall(FunctionCallInfo fcinfo, bits32 flags)
> +{
> + InitMaterializedSRF(fcinfo, flags);
On Fri, Oct 14, 2022 at 7:41 PM Michael Paquier wrote:
> On Fri, Oct 14, 2022 at 05:09:46PM -0400, Melanie Plageman wrote:
> > To summarize, I am in support of renaming SetSingleFuncCall() ->
> > InitMaterializedSRF() and SRF_SINGLE_USE_EXPECTED ->
> > MAT_SRF_USE_EXPECTED_TUPLE_DESC (or just DES
On Fri, Oct 14, 2022 at 05:09:46PM -0400, Melanie Plageman wrote:
> To summarize, I am in support of renaming SetSingleFuncCall() ->
> InitMaterializedSRF() and SRF_SINGLE_USE_EXPECTED ->
> MAT_SRF_USE_EXPECTED_TUPLE_DESC (or just DESC) as suggested elsewhere in
> this thread. And I think we should
Melanie Plageman writes:
> So, while I agree that the "Single" in SetSingleFuncCall() could be
> confusing given the name of ExprSingleResult, I feel like actually all
> of the names are somewhat wrong.
Maybe, but ExprSingleResult et al. have been there for decades and
are certainly embedded in a
On Thu, Oct 13, 2022 at 3:48 PM Andres Freund wrote:
> I unfortunately just noticed this now, just after we released...
>
> In
>
> commit 9e98583898c347e007958c8a09911be2ea4acfb9
> Author: Michael Paquier
> Date: 2022-03-07 10:26:29 +0900
>
> Create routine able to set single-call SRFs for
Hi,
On 2022-10-14 10:28:34 +0900, Michael Paquier wrote:
> On Thu, Oct 13, 2022 at 12:48:20PM -0700, Andres Freund wrote:
> > Maybe something like InitMaterializedSRF() w/
> > MAT_SRF_(USE_EXPECTED_DESC|BLESS)
>
> Or just SetMaterializedFuncCall()?
I think starting any function that's not a sett
On Thu, Oct 13, 2022 at 12:48:20PM -0700, Andres Freund wrote:
> I unfortunately just noticed this now, just after we released...
Thanks for the feedback.
> Even leaving the confusion with ExprSingleResult aside, calling it "Single"
> still seems very non-descriptive. I assume it's named to contr
12 matches
Mail list logo
