| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Client application name |
| Date: | 2009-10-21 17:57:26 |
| Message-ID: | 4ADF4B86.5020204@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> That options hack was just an ugly hack, I don't like it at all ---
> mainly because I don't believe that approach scales to solve more
> than one case either.
It does if you hack it even more: don't pass the (first) options
directly as command line arguments, but parse it in ProcessStartupPacket
into a list of GUC settings. Add the ones that the server version
understands into the usual list of GUCs to set, and ignore others.
Yeah, ugly as hell, but does scale if used wisely.
One possible issue is that there might be 3rd party applications out
there that speak the fe/be protocol, like proxies. They might not like
an extra options line. I don't think it's a show-stopper, but would need
to check at least the popular ones out there.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2009-10-21 17:59:21 | Re: Controlling changes in plpgsql variable resolution |
| Previous Message | Tom Lane | 2009-10-21 17:52:55 | Prelim specs for parser hooks for plpgsql |