From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: proposal: session server side variables |
Date: | 2017-02-03 10:19:16 |
Message-ID: | CAFj8pRB-mqezC8o7SAT2VoOcvxKhusz8opLGrePPbe=6uVs82A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
>
>
>>
>> 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.
>>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-02-03 10:21:28 | Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal |
Previous Message | Fabien COELHO | 2017-02-03 10:18:56 | Re: proposal: session server side variables |