Re: proposal: session server side variables

2016-12-26 8:30 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Jim,
>
> If you want to ignore performance, there are things you can do with
>> non-transactional variables that are simply not possible with tables. But
>> even ignoring that, the performance cost of temp tables is massive compared
>> to variables.
>>
>
> Ok, then read "variables are like tables" instead of "variables are
> tables". Note that I'm definitely interested in performance in the end, but
> I'm first interested in discussing features.
>
> Currently I'm unconvinced by a proposal of variables that are in the
> relation namespace (pg_class), are subject to GRANT/REVOKE, are managed
> with CREATE/DROP *but* are somehow partly non transactional, and only alive
> through sessions, and are only accessed through functions...
>
> My current thinking is that the proposed design is either too heavy
> (pg_class, permissions) or too light (then why not possible persistence
> and/or transactions?): I would be more at ease with very light-weight
> typed? session variables stored in the server process "as is", without any
> attempt at pg_class & permissions, or with more full featured variables,
> but not something half-baked which seems designed for a particular use case
> that I do not have.
>
> Not only is the access far more complex, but bloating is a major problem
>> (both in the table itself as well as in the catalog). That's part of the
>> driver for all the discussion about things like permanent temp tables
>> (which still leaves a bloat and performance problem in the table itself).
>>
>
> If a variable as currently discussed is in pg_class and subject to
> permissions, then probably it will cost on the catalog side anyway, and at
> least their existent would be transactional even if their value is not.
>

the access right check has **constant** small cost (check in object cache).
The proposed variables has not any negative effect on catalogue bloating
because a metadata are persistent.

It is reason why I use statement "CREATE VARIABLE", not "DECLARE VARIABLE"

Regards

Pavel

>
> --
> Fabien.
>