On 30 December 2016 at 14:50, Fabien COELHO <coe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
