On 30 December 2016 at 14:50, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
>>> I know this one. It can be empty, which a singleton cannot be. For a
>>> singleton table, you should have one and only one row, you cannot insert or
>>> delete, so this is only part of the real thing.
>>
>>
>> Surely we can do a bit better than that, if that's what you really want.
>> Create the table with an initial row and add a trigger preventing anything
>> except update.
>
>
> Yes.
>
> I just meant that this is not available easily "out of the box", but it is
> obviously doable with some effort... which people would seldom do.
Sure... but every feature has a cost too, in maintenance and reliability.
This needs to have compelling use cases, and it's not free to add
multiple similar-ish/overlapping features. So some agreement on what
we should actually have is needed, along with a compelling case for
what it delivers that we can't already do.
Pavel's personal requirements include that it be well suited for
static analysis of plpgsql using his plpgsql_check tool. So he wants
persistent definitions.
You expect different things from variables, to the point where it's a
different feature.
It's unlikely two unrelated variable implementations will be accepted.
I think progress can only be achieved by setting out requirements, a
feature matrix, and which proposed implementations can deliver which
desired features. Then go from there.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services