Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date: 2013-08-09 12:44:05
Message-ID: 20130809124404.GY2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> > What I'm yet unsure about is that there's a consensus that the use cases
> > are worthy of a new shared catalog in the system. Also I didn't look how
> > hard it is to actually provide for it.
>
> A new shared catalog wouldn't actually help, because the actual
> procedure to be run has to live in pg_proc, which is not shared. And
> that has references to all sorts of other things (like pg_language)
> that aren't shared either.

A shared catalog which defined which *database* to run the trigger in,
with a way to fire off a new backend worker in that database and tell it
to run the trigger, might be interesting and would deal with the issue
that the trigger would behave differently depending on the database
connected to. That would bring along other issues, of course, but it
seemed an interesting enough idea to mention.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-08-09 13:05:51 Re: mvcc catalo gsnapshots and TopTransactionContext
Previous Message Romain Billon-Grand 2013-08-09 10:40:29 Re: BUG #8335: trim() un-document behaviour