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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
