>
>
>
>
>>
>> My "hard" opinion is that providing an unsafe by default feature (i.e.
>> which works as in some particular cases, but may fail silently if the
>> transaction fails), especially for a security related use case which
>> motivates the whole feature addition, is a very bad idea for the product.
>> If a committer likes it anyway, good for you.
>>
>
> I respect to your opinion and I understand - I have a similar strong
> opinion on packages in Postgres. In this case I prefer a common
> implementation - and common expectation.
>
> When some feature is PostgreSQL original, then we can design how we can.
> But when we implement some feature that exists already, then we should to
> respect some previous, older major implementation.
>
> The great example is our implementation of OUT parameters in PL. The idea
> is great - modern languages use it Golang, Rust. But in PL area is unique,
> different. One from significant issues migrations to Postgres, Postgres
> adoptions is this small feature.
>
> The people who is working with stored procedures doesn't expect XA behave,
> overhead when they working with some objects named "variables". We can
> implement XA support for variables, ale I don't think so default should be
> XA. Only few cases where variables can be used are are XA sensitive.
>
A syntax can be designed very verbose, so anybody can see and should to
choose expected behave of variables
CREATE [ { TEMPORARY | TEMP } ] [ { TRANSACTIONAL | XA } ] VARIABLE [ IF
NOT EXISTS ] varname datatype [ DEFAULT default_expression ] ;
Regards
Pavel
>
> Regards
>
> Pavel
>
>
>>
>> Other opinions I expressed on the thread are somehow "softer", i.e. even
>> if I think that there are better (simpler, easier) alternatives, these are
>> only alternatives.
>>
>> --
>> Fabien.
>>
>
>
