On Tuesday 23 September 2003 01:19, Mike Mascari wrote:
> 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.
Not for what I was thinking of (see below).
> 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...
From the PHP/webapp point of view, you need the ability to store a _single_
value so you can reference a permanent session-table. You use your session
table to store the actual values. Temporary tables mean I am doing one of two
things:
1. Creating a table to store one value, repopulating it on every connection.
2. Handling all my session values in the scripting language and
creating/populating a table to hold them all.
Neither is quite as convenient as CURRENT_SESSION_ID or whatever it might be
called. All that needs to do is store one text value (which covers text and
numeric session ids), ideally with the option of "locking" it so once set it
cannot be changed until a disconnect. The locking needs to be optional for
those using connection pooling.
> This gives them that opportunity. Perhaps its usefulness doesn't
> warrant a contrib module though...
Given that a lot of the target audience for this might be sharing an
installation of PG, it would need to be something fairly widely installed.
Given that they're not necessarily experienced DBAs it needs to be something
simple to use and understand.
PS - thanks for ccing me on this, I wasn't subscribed to -patches.
--
Richard Huxton
Archonet Ltd
