On Fri, Dec 10, 2021 at 10:10 AM Godfrin, Philippe E
wrote:
> I may have missed something in this stream, but is this a system controlled
> by Patroni?
In my case, no: it's a pretty vanilla PGDG install on Ubuntu 20.04.
Thanks for the context, though.
Thanks,
Maciek
On Thu, Dec 9, 2021 at 7:42 AM Bharath Rupireddy
wrote:
> How about ALTER SYSTEM SET shared_preload_libraries command itself
> checking for availability of the specified libraries (after fetching
> library names from the parsed string value) with stat() and then
> report an error if any of the
On Thu, Dec 9, 2021 at 2:32 AM Maciek Sakrejda wrote:
> > Considering the vanishingly small number of actual complaints we've
> > seen about this, that sounds ridiculously over-engineered.
> > A documentation example should be sufficient.
>
> I don't know if this will tip the scales, but I'd like
On Wed, Dec 1, 2021 at 5:15 AM Tom Lane wrote:
>
> Justin Pryzby writes:
> > +1 to document it, but it seems like the worse problem is allowing
> > +the admin to
> > write a configuration which causes the server to fail to start,
> > without having issued a warning.
>
> > I think you could
On Thu, Dec 9, 2021 at 1:02 PM Maciek Sakrejda wrote:
>
> On Wed, Dec 1, 2021 at 5:15 AM Tom Lane wrote:
> >
> > Justin Pryzby writes:
> > > +1 to document it, but it seems like the worse problem is allowing the
> > > admin to
> > > write a configuration which causes the server to fail to
On Wed, Dec 1, 2021 at 5:15 AM Tom Lane wrote:
>
> Justin Pryzby writes:
> > +1 to document it, but it seems like the worse problem is allowing the
> > admin to
> > write a configuration which causes the server to fail to start, without
> > having
> > issued a warning.
>
> > I think you could
On Mon, Dec 6, 2021 at 9:20 PM Bharath Rupireddy
wrote:
>
> On Fri, Dec 3, 2021 at 11:25 PM Bossart, Nathan wrote:
> >
> > On 12/3/21, 6:21 AM, "Bharath Rupireddy"
> > wrote:
> > > +1 to add here in the "Parameter Names and Values section", but do we
> > > want to backlink every string
Bharath Rupireddy writes:
> Am I missing something here? Or is there a distinction between parsing
> of postgresql.conf and ALTER SYSTEM SET command for GUC_LIST_QUOTE
> values? If so, what is it?
One context is SQL, the other is not. The quoting rules are
really quite different.
On Fri, Dec 3, 2021 at 11:25 PM Bossart, Nathan wrote:
>
> On 12/3/21, 6:21 AM, "Bharath Rupireddy"
> wrote:
> > +1 to add here in the "Parameter Names and Values section", but do we
> > want to backlink every string parameter to this section? I think it
> > needs more effort. IMO, we can just
On 12/3/21, 6:21 AM, "Bharath Rupireddy"
wrote:
> +1 to add here in the "Parameter Names and Values section", but do we
> want to backlink every string parameter to this section? I think it
> needs more effort. IMO, we can just backlink for
> shared_preload_libraries alone. Thoughts?
IMO this
On Fri, Dec 3, 2021 at 6:33 AM Michael Paquier wrote:
>
> On Fri, Dec 03, 2021 at 12:45:56AM +, Bossart, Nathan wrote:
> > I think the problems you noted upthread are shared for all GUCs with
> > type GUC_LIST_QUOTE (e.g., search_path, temp_tablespaces). Perhaps
> > the documentation for
On Fri, Dec 03, 2021 at 12:45:56AM +, Bossart, Nathan wrote:
> I think the problems you noted upthread are shared for all GUCs with
> type GUC_LIST_QUOTE (e.g., search_path, temp_tablespaces). Perhaps
> the documentation for each of these GUCs should contain a short blurb
> about how to
On 12/1/21, 5:59 AM, "Bharath Rupireddy"
wrote:
> On Wed, Dec 1, 2021 at 6:45 PM Tom Lane wrote:
>> Considering the vanishingly small number of actual complaints we've
>> seen about this, that sounds ridiculously over-engineered.
>> A documentation example should be sufficient.
>
> Thanks.
On Wed, Dec 1, 2021 at 6:45 PM Tom Lane wrote:
>
> Justin Pryzby writes:
> > +1 to document it, but it seems like the worse problem is allowing the
> > admin to
> > write a configuration which causes the server to fail to start, without
> > having
> > issued a warning.
>
> > I think you could
Justin Pryzby writes:
> +1 to document it, but it seems like the worse problem is allowing the admin
> to
> write a configuration which causes the server to fail to start, without having
> issued a warning.
> I think you could fix that with a GUC check hook to emit a warning.
> I'm not sure
On Wed, Dec 01, 2021 at 04:20:52PM +0530, Bharath Rupireddy wrote:
> It seems like users can try different ways to set multiple values for
> shared_preload_libraries GUC even after reading the documentation
> [1]), something like:
...
> ALTER SYSTEM SET shared_preload_libraries =
>
Hi,
It seems like users can try different ways to set multiple values for
shared_preload_libraries GUC even after reading the documentation
[1]), something like:
ALTER SYSTEM SET shared_preload_libraries TO
auth_delay,pg_stat_statements,sepgsql; --> correct
ALTER SYSTEM SET
if written in such a way and don't report
unexpected behaviour especially for the use cases like (2) where they
might expect ONLY foo behaviour but it is skipped by the server.
AFAICS, I don't find it anywhere in the docs, should we document it as
a note?
Thoughts?
With Regards,
Bharath Rupireddy.
En
On Thu, Nov 19, 2020 at 6:43 PM Tom Lane wrote:
> After digging a bit more I noticed that we'd discussed removing
> IS OF in the 2007 thread, but forebore because there wasn't an easy
> replacement. pg_typeof() was added a year later (b8fab2411), so we
> could have done this at any point since
Howdy,
Well I certainly wasn't trying to make work out of that blog but I am glad
to see it was productive.
JD
On Thu, Nov 19, 2020 at 2:43 PM Tom Lane wrote:
> After digging a bit more I noticed that we'd discussed removing
> IS OF in the 2007 thread, but forebore because there wasn't an
After digging a bit more I noticed that we'd discussed removing
IS OF in the 2007 thread, but forebore because there wasn't an easy
replacement. pg_typeof() was added a year later (b8fab2411), so we
could have done this at any point since then.
Pushed.
regards, tom lane
Joe Conway writes:
> On 11/19/20 12:08 PM, Tom Lane wrote:
>> Here's a proposed patch for that. I was amused to discover that we have
>> a couple of regression test cases making use of IS OF.
> I didn't check but those might be my fault ;-)
I suspect at least one of them is mine ;-). But I
On 11/19/20 12:08 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote:
>>> On 11/19/20 11:06 AM, Tom Lane wrote:
Let's just rip it out and be done. If anyone is ever
motivated to make it work per spec, they can resurrect
Bruce Momjian writes:
> On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote:
>> On 11/19/20 11:06 AM, Tom Lane wrote:
>>> Let's just rip it out and be done. If anyone is ever
>>> motivated to make it work per spec, they can resurrect
>>> whatever seems useful from the git history.
>> +1
On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote:
> On 11/19/20 11:06 AM, Tom Lane wrote:
> > Let's just rip it out and be done. If anyone is ever
> > motivated to make it work per spec, they can resurrect
> > whatever seems useful from the git history.
>
> +1
+1
--
Bruce Momjian
On 11/19/20 11:06 AM, Tom Lane wrote:
> Let's just rip it out and be done. If anyone is ever
> motivated to make it work per spec, they can resurrect
> whatever seems useful from the git history.
+1
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Joe Conway writes:
> Here is a link to previous list discussions:
> https://www.postgresql.org/message-id/45DA44F3.3010401%40joeconway.com
Ah, thanks, I was intending to go do some searching for that.
So at this point this has been re-debated at least three times.
I think it's time to put it
On 11/19/20 2:03 AM, Tom Lane wrote:
> "David G. Johnston" writes:
>> Is there a feature code? I skimmed the standard and non-standard tables in
>> our appendix and couldn’t find this in either.
>
> a19d9d3c4 seems to have thought it was S151.
Here is a link to previous list discussions:
"David G. Johnston" writes:
> Is there a feature code? I skimmed the standard and non-standard tables in
> our appendix and couldn’t find this in either.
a19d9d3c4 seems to have thought it was S151.
regards, tom lane
On Wednesday, November 18, 2020, Tom Lane wrote:
> I wrote:
> > So my vote would be to rip it out, not document it. Somebody can try
> > again in future, perhaps. But if we document it we're just locking
> > ourselves into a SQL incompatibility.
>
> Apparently, somebody already had that
I wrote:
> So my vote would be to rip it out, not document it. Somebody can try
> again in future, perhaps. But if we document it we're just locking
> ourselves into a SQL incompatibility.
Apparently, somebody already had that thought. See func.sgml
lines 765-782, which were commented out by
"David G. Johnston" writes:
> Over in news [1] Josh Drake and Eric Ridge discovered the undocumented
> feature "IS [NOT] OF"; introduced seemingly as an "oh-by-the-way" in 2002
> via commit eb121ba2cfe [2].
> Is there any reason not to document this back to 9.5,
As far as I can tell from
Hackers,
Over in news [1] Josh Drake and Eric Ridge discovered the undocumented
feature "IS [NOT] OF"; introduced seemingly as an "oh-by-the-way" in 2002
via commit eb121ba2cfe [2].
Is there any reason not to document this back to 9.5, probably with a note
nearby to pg_typeof(any), which is a
33 matches
Mail list logo
