From: | John McCawley <nospam(at)hardgeus(dot)com> |
---|---|
To: | Erik Jones <erik(at)myemma(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Any form of connection-level "session variable" ? |
Date: | 2007-01-04 20:18:13 |
Message-ID: | 459D6105.9090003@hardgeus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I tried stable, and that didn't help at all. How long does PostgreSQL
maintain the "state" of the function when using immutable? Until a
restart? Until the end of a session? Until the function is dropped and
re-added?
While this value isn't 100% absolutely positively guaranteed to never
change, it is pretty dang close. I have a strict correlation between
the username that someone uses to login and the ID returned. Changing
someone's username would break a whole lot more than this one app on the
project...
Erik Jones wrote:
> Tom Lane wrote:
>
>> John McCawley <nospam(at)hardgeus(dot)com> writes:
>>
>>
>>> I think I got it:
>>> CREATE FUNCTION new_get_emp_id() RETURNS INTEGER AS $$ select emp_id
>>> from secureview.tbl_employee where username = (SELECT current_user)
>>> $$ LANGUAGE SQL IMMUTABLE;
>>> I made the function immutable so it only calls it once, therefore no
>>> longer requiring a call per-row.
>>>
>>
>>
>> Since it's obviously *not* immutable, this will come back to bite you
>> sooner or later (probably sooner). Labeling it STABLE would be
>> reasonable, although I'm not certain how much that helps you. Do you
>> have indexes on the columns it's being compared to?
>>
>
> Besides, a temp table is pretty much a session variable.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-01-04 20:26:16 | Re: Any form of connection-level "session variable" ? |
Previous Message | Scott Ribe | 2007-01-04 20:17:41 | Bug in 8.2 (&8.1) dump & restore |