Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>
>>We've rejected session variables many times before because they duplicate
>>temporary tables. I don't see anything new added by this proposal.
>
> I should think there would be a notable performance advantage, since
> one need not create a temp table (which in our current implementation is
> just as expensive as creating a permanent table); not to mention
> dropping the temp table later, vacuuming up the resulting dead rows in
> pg_class and pg_attribute, etc. Whether that advantage is great enough
> to justify a nonstandard feature is unproven, but I imagine Mike could
> answer it with a little experimentation.
Yes. I guess the lifetime of this contrib module would be short - SQL
temporary tables that don't suffer those performance penalties would
be the correct solution.
I think it might be useful to some in the interim. From what I've seen
on the mailing lists, people would like to build VIEW driven
applications where the application maintains users and therefore they
don't have the ability to leverage CURRENT_USER in view definitions...
This gives them that opportunity. Perhaps its usefulness doesn't
warrant a contrib module though...
Mike Mascari
mascarm@mascari.com
