| From: | Dave Page <dpage(at)pgadmin(dot)org> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Client application name |
| Date: | 2009-10-13 15:45:47 |
| Message-ID: | 937d27e10910130845g2b9c758aj1a8df767fd309ea6@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> From time to time people ask for "scalar variable" facility. ISTM what
> you're trying to do is just a special case of that. Maybe we could approach
> it by providing a builtin (and non-removable) custom_variable_classes entry
> ('pg_variables'?). Then you could have clients safely do:
>
> set pg_variables.client_name = 'blurfl';
>
> And I'm sure other people would find interesting uses for such a gadget.
I'm not sure that's really related to this - for example, we wouldn't
want to push everything in the custom class through the logger or into
per-backend shared memory, which would mean special-casing this
particular variable for which doing those things is the primary use
case.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-10-13 16:05:13 | Re: Client application name |
| Previous Message | Tom Lane | 2009-10-13 15:41:40 | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) |