On 12/1/20 9:49 AM, Abhijit Menon-Sen wrote:
Therefore, for lack of any plausible way to proceed, I do not plan to
work on this feature any more.
It sounds like this CF entry should be closed. I'll do that on March 12
unless somebody beats me to it.
Regards,
--
-David
da...@pgmasters.net
On Tue, Dec 1, 2020 at 08:19:34PM +0530, Abhijit Menon-Sen wrote:
> 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
At 2020-10-28 18:29:30 -0700, and...@anarazel.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.co
Hi,
On 2020-10-21 10:05:40 +0530, Abhijit Menon-Sen wrote:
> > It seems to me that appending and incrementing using the same syntax
> > is a) confusing b) will be a limitation before long.
>
> I understand (a), but what sort of limitation do you foresee in (b)?
>
> Do you think both features sho
At 2020-10-20 10:53:04 -0700, and...@anarazel.de wrote:
>
> > postgres=# ALTER SYSTEM SET max_worker_processes += 4;
> > ALTER SYSTEM
>
> Much less clear that this is a good idea...
I agree it's less clear. I still think it might be useful in some cases
(such as the example with max_worke
On Tue, Oct 20, 2020 at 3:24 PM Andres Freund wrote:
> As far as I understand what the proposal does, if you were to do do an
> ALTER SYSTEM like you do, it'd actually write an "absolute"
> shared_preload_libraries value to postgresql.auto.conf. So if you then
> subsequently modified the shared_pr
Hi,
On 2020-10-20 14:39:42 -0400, Robert Haas wrote:
> On Tue, Oct 20, 2020 at 2:34 PM Alvaro Herrera
> wrote:
> > On 2020-Oct-20, Tom Lane wrote:
> > > and the fact that we've gone twenty-odd years without similar
> > > previous proposals doesn't speak well for it being really useful.
> >
> > A
On Tue, Oct 20, 2020 at 2:34 PM Alvaro Herrera wrote:
> On 2020-Oct-20, Tom Lane wrote:
> > and the fact that we've gone twenty-odd years without similar
> > previous proposals doesn't speak well for it being really useful.
>
> Actually, there's at least two threads about this:
>
> https://postgr.
On 2020-Oct-20, Tom Lane wrote:
> and the fact that we've gone twenty-odd years without similar
> previous proposals doesn't speak well for it being really useful.
Actually, there's at least two threads about this:
https://postgr.es/m/flat/86d2ceg611@jerry.enova.com
https://postgr.es/m/flat/
Andres Freund writes:
> On 2020-10-20 14:16:12 -0400, Tom Lane wrote:
>> I'd make that point against the whole proposal. There's nothing here that
>> can't be done with current_setting() + set_config().
> The one case where I can see SET support being useful even without
> config support is to a
Hi,
On 2020-10-20 14:16:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Given that this is just SQL level, I don't see why we'd need a special
> > type of language here. You can just use DO etc.
>
> I'd make that point against the whole proposal. There's nothing here that
> can't be done
Andres Freund writes:
> Given that this is just SQL level, I don't see why we'd need a special
> type of language here. You can just use DO etc.
I'd make that point against the whole proposal. There's nothing here that
can't be done with current_setting() + set_config(). I'm pretty dubious
abou
On Sun, 27 Sep 2020 at 23:39, Abhijit Menon-Sen wrote:
> postgres=# SET search_path += octopus;
> SET
> postgres=# SET search_path += "giant squid", kraken, narwhal; -- [1]
> SET
> postgres=# SET search_path -= public, narwhal;
> SET
> postgres=# SHOW search_path;
>
Hi,
On 2020-09-28 09:09:24 +0530, Abhijit Menon-Sen wrote:
> postgres=# SET search_path += octopus;
> SET
Yea, that would be quite useful!
> The second patch
> (0002-Support-SET-syntax-for-numeric-configuration-setting.patch) adds
> support to modify numeric configuration settings:
>
On 2020-10-20 13:02, Ibrar Ahmed wrote:
The following review has been posted through the commitfest
application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Thanks for the patch.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Thanks for the patch. The patch works on my machine as per specs
16 matches
Mail list logo
