Robert Haas <robertmh...@gmail.com> writes: > On Tue, Sep 6, 2022 at 1:43 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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.
> Well, I've thought about doing this a few times, but it's a real pain > in the neck, primarily because we store metadata that needs to be > per-instantiation in the catalog rows: relfrozenxid, relminmxid, and > the relation statistics. So I'm not sure "no one has bothered" is > quite the right way to characterize it. "no one has been able to > adequately untangle the mess" might be more accurate. I could agree on "no one has thought it was worth the work". It could be made to happen if we were sufficiently motivated, but we aren't. I believe a big chunk of the reason is that the SQL semantics are not obviously better than what we have. And some of the advantages they do have, like less catalog thrashing, wouldn't apply in the session variable case. > I haven't looked at that patch at all, but I would assume that > variables would have SQL types, and that we would never add GUCs with > SQL types, which seems like a pretty major semantic difference. Yeah, I do not think we'd want to extend GUCs beyond the existing bool/int/float/string cases, since they have to be readable under non-transactional circumstances. Having said that, that covers an awful lot of practical territory. Schema variables of arbitrary SQL types sound cool, sure, but how many real use cases are there that can't be met with the GUC types? I think a large part of the reason the schema-variables patch has gone sideways for so many years is that it's an ambitious overdesign. regards, tom lane