Hello Tom,
Hmmm. If a variable is implemented as a one row table, then constraints
are already available there, as well as grant & revoke, they can be any
type including composite, nearly nothing to implement to get...
A "one row" table would be a CREATE + one INSERT, UPDATE allowed, further
INSERT and DELETE are disallowed by construction. Then some syntactic
sugar for variables (session => temporary table, persistent => standard
table). Note sure about a "transaction variable", though... maybe an
[unlogged] table automatically dropped on commit?
I think it's entirely silly
Thanks for "silly". Last time it was "academic". Is it better? :-)
to be inventing something that's morally a one-row table, when we
already have perfectly good one-row tables.
Hmmm. Although I can think of ways to ensure that a table is one row
(unique, check, trigger, rules, whatever...), none are straightforward.
The value of a server-side variable facility would be mostly that it
doesn't have all the overhead implied by tables.
I do not know that. I think that discussing semantics and syntax does
have value as well.
ISTM that there are 4 intermixed issues related to server-side variables:
(1) what should be their possible semantics and capabilities
e.g. with respect to transactions, permissions, namespace, types,
constraints, ...
=> what is the use cases for them?
(2) what should be their syntax
=> what do you want do write to use them?
(3) how to implement them
(4) how to optimize the implementation, eventually
I think that a special purpose variable infrastructure implied by your
remark is just starting from the end point. The first three points seem
relevant too because they help focus on other issues.
I'm not claiming that having variables as one-row tables is the best ever
solution, but I do not think that it is such a terrible idea either. At
least it provides a clear and consistent range of existing semantics out
of the box (unlogged/temporary/standard, permissions...), thus provide a
clean model for discussion, even if it is rejected for some reason
afterwards.
Also it seems easy to implement (as syntactic sugar) and play with, and
I'm not sure that sure that performance would be that bad, as for session
(temporary unlogged?) variables they would probably simply stay in cache.
If the performance is an issue in concrete use cases they could be
optimized in the end, to reduce time and space, which would be great.
I think that is a direct reason not to think about overhead like
constraints, as well.
Hmmm. If there is no constraint, the overhead is limited? If one has use
for constraints, then they can pay the overhead?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
