út 6. 9. 2022 v 7:42 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Pavel Stehule <pavel.steh...@gmail.com> writes: > > út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule <pavel.steh...@gmail.com> > > napsal: > >> 1. Session variables can be persistent - so the usage of session > variables > >> can be checked by static analyze like plpgsql_check > > > more precious - metadata of session variables are persistent > > Right ... so the question is, is that a feature or a bug? > > I think there's a good analogy here to temporary tables. The SQL > spec says that temp-table schemas are persistent and database-wide, > but what we actually have is that they are session-local. People > occasionally propose that we implement the SQL semantics for that, > but in the last twenty-plus years no one has bothered to write a > committable patch to support it ... much less remove the existing > behavior in favor of that, which I'm pretty sure no one would think > is a good idea. > > So, is it actually a good idea to have persistent metadata for > session variables? I'd say that the issue is at best debatable, > and at worst proven wrong by a couple of decades of experience. > In what way are session variables less mutable than temp tables? > The access pattern is very different. The session variable is like the temp table with exactly one row. It reduces a lot of overheads with storage (for reading, for writing). For example, the minimum size of an empty temp table is 8KB. You can store all "like" session values to one temp table, but then there will be brutal overhead with reading. > > Still, this discussion would be better placed on the other thread. > sure - faster GUC is great - there are a lot of applications that overuse GUC, because there are no other solutions now. But I don't think so it is good solution when somebody need some like global variables in procedural code. And the design of session variables is more wide. Regards Pavel > > regards, tom lane >
