Re: proposal: session server side variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: session server side variables
Date: 2016-12-30 08:46:06
Message-ID: alpine.DEB.2.20.1612300923430.32017@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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.

I've been in static analysis for the last 25 years, and the logic of this
statement fails me.

Pavel wants that the plpgsql_check tool can statically analyse session
variables, which is fine with me.

It does not fellow that the definition must be "persistent" as such, it
fellows that it should be available in the PL/pgSQL script so that a tool
which reads it can check it by looking at the codes. IMO this is a lesser
requirement.

I do not think that a feature should be designed around the current
limitations of a particular external tool, esp. if said tool can be
improved at a reasonable cost.

> 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.

Yep. I've bootstapped a wiki page, feel free to improve it as you see fit:

https://wiki.postgresql.org/wiki/Variable_Design

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2016-12-30 08:59:32 Re: Add doc advice about systemd RemoveIPC
Previous Message Ashutosh Bapat 2016-12-30 08:20:53 Re: Potential data loss of 2PC files