Re: [PATCH] SET search_path += octopus

From: Abhijit Menon-Sen <ams(at)toroid(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] SET search_path += octopus
Date: 2020-12-01 14:49:34
Message-ID: X8ZX/ktE5PrOhdin@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2020-10-28 18:29:30 -0700, andres(at)anarazel(dot)de wrote:
>
> I think my gut feeling about this still is that it's not worth
> implementing something that doesn't work in postgresql.conf. The
> likelihood of ending up with something that makes it hard to to
> eventually implement proper postgresql.conf seems high.

OK, thanks for explaining. That seems a reasonable concern.

I can't think of a reasonable way to accommodate the variety of possible
modifications to settings in postgresql.conf without introducing some
kind of functional syntax:

shared_preload_libraries =
list('newval', $shared_preload_libraries, 'otherval')

I rather doubt my ability to achieve anything resembling consensus on a
feature like that, even if it were restricted solely to list operations
on a few settings to begin with. I am also concerned that such a feature
would make it substantially harder to understand where and how the value
of a particular setting is derived (even if I do find some way to record
multiple sources in pg_settings—a problem that was brought up in earlier
discussions).

I'm certainly not in favour of introducing multiple operators to express
the various list operations, like += for prepend and =+ for append. (By
the standard of assembling such things from spare parts, the right thing
to do would be to add M4 support to postgresql.conf, but I'm not much of
a fan of that idea either.)

Therefore, for lack of any plausible way to proceed, I do not plan to
work on this feature any more.

-- Abhijit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2020-12-01 14:52:05 Re: Corner-case bug in pg_rewind
Previous Message Anastasia Lubennikova 2020-12-01 14:41:17 Re: Corner-case bug in pg_rewind