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 
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

Reply via email to