From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parsing config files in a directory |
Date: | 2009-11-10 14:39:54 |
Message-ID: | 1257863994.5363.1272.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2009-11-10 at 08:59 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > All of this *also* applies to shared_preload_libraries. We also need to
> > be able to specify new load libraries without editing the same darn
> > parameter.
>
> And to search_path, though that's even more complex because the order of
> the entries is significant.
Yes, good thought.
It would be useful to have some way to express dependency there, rather
than just sequence.
search_path_add = 'my_module1, my_module2'
search_path_depends = 'postgis'
So that we can assemble a search_path with final sequence based upon the
dependency tree, rather than risk a weird sequence.
We might need to have a special keyword in the main search_path to show
where additions go, e.g.
search_path = '$user, $install, public, pg_catalog'
This is beginning to sound like a very workable mechanism for plugins.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2009-11-10 14:56:44 | Re: Query::targetList and RETURNING |
Previous Message | Tom Lane | 2009-11-10 14:38:59 | Re: Query::targetList and RETURNING |