> So in conclusion we have 3 possible paths to go with this
>
> 1) Just don't allow any extensions referenced by other extensions to be
> relocatable.
> It will show a message something like
> "SET SCHEMA not allowed because other extensions depend on it"
> Given that if you don't specify
On Sat, Feb 25, 2023 at 08:58:17PM -0800, Nathan Bossart wrote:
> pg_input_error_info() seems more descriptive to me. I changed the name to
> that in v4.
error_info() is fine by me. My recent history is poor lately when it
comes to name new things.
+ values[0] =
On Sat, Feb 25, 2023 at 08:07:33PM -0500, Tom Lane wrote:
> Maybe pg_input_error_info()? I tend to agree with Michael that as
> soon as you throw things like the SQLSTATE code into it, "message"
> seems not very apropos. I'm not dead set on that position, though.
pg_input_error_info() seems
On Sat, Feb 25, 2023 at 11:24:17AM +0530, Amit Kapila wrote:
> On Wed, Feb 22, 2023 at 12:13 PM Julien Rouhaud wrote:
> >
> > > Is there really a use case for dumping the content of pg_subscription_rel
> > > outside of pg_upgrade?
>
> I think the users who want to take a dump and restore the
On Fri, Feb 24, 2023 at 01:18:40PM -0600, Justin Pryzby wrote:
> This is a draft patch - review is welcome and would help to get this
> ready to be considererd for v16, if desired.
>
> I'm going to add this thread to the old CF entry.
> https://commitfest.postgresql.org/31/2888/
This resolves
On 1/4/23 12:57, Alvaro Herrera wrote:
I haven't read this patch other than superficially; I suppose the
feature it's introducing is an OK one to have as an extension to the
standard. (I hope the community members that are committee members
will propose this extension to become part of the
Nathan Bossart writes:
> On Sat, Feb 25, 2023 at 01:39:21PM +0900, Michael Paquier wrote:
>> pg_input_error_message() does not strike me as a good function name,
>> though, because it now returns much more than an error message.
>> Hence, couldn't something like pg_input_error() be better,
On Sat, Feb 25, 2023 at 01:39:21PM +0900, Michael Paquier wrote:
> pg_input_error_message() does not strike me as a good function name,
> though, because it now returns much more than an error message.
> Hence, couldn't something like pg_input_error() be better, because
> more generic?
I
On Sat, Feb 25, 2023 at 10:29:33AM -0800, Andres Freund wrote:
> Hi,
>
> On 2022-12-28 17:44:47 -0800, Andres Freund wrote:
> > On 2022-12-28 18:35:38 -0600, Justin Pryzby wrote:
> > > Since a few days ago, the windows/meson task has been spewing messages
> > > for each tap
> > > test:
> > >
>
On Sat, Feb 25, 2023 at 11:52:53AM -0800, Andres Freund wrote:
> I think I opined on this before, but we really ought to have a function to do
> some minimal signal safe output. Implemented centrally, instead of being open
> coded in a bunch of places.
While looking around for the right place to
Hi,
Around
https://www.postgresql.org/message-id/20230224015417.75yimxbksejpffh3%40awork3.anarazel.de
I suggested that we should evaluate the arguments of correlated SubPlans as
part of the expression referencing the subplan.
Here's a patch for that.
Ended up simpler than I'd thought. I see
On Sat, Feb 25, 2023 at 9:32 PM Joseph Yu wrote:
> hi community
>
> This is the first time for me to submit a patch to Postgres community.
>
> instead of using for loop to find the most significant bit set. we could
> use __builtin_clz function to first find the number of leading zeros for
> the
> On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote:
> >
> > Attached is a revised version of the original patch. It is revised to
> > prevent
> >
> > ALTER EXTENSION .. SET SCHEMA if there is a dependent extension that
> > references the extension in their scripts using
> >
hi community
This is the first time for me to submit a patch to Postgres community.
instead of using for loop to find the most significant bit set. we could
use __builtin_clz function to first find the number of leading zeros for
the mask and then we can find the index by 32 -
Hi,
As suggested in [1], the attached patch adds shared buffer hits to
pg_stat_io.
I remember at some point having this in the view and then removing it
but I can't quite remember what the issue was -- nor do I see a
rationale mentioned in the thread [2].
It might have had something to do with
Hi,
On 2023-02-25 11:28:25 -0800, Nathan Bossart wrote:
> On Sat, Feb 25, 2023 at 11:07:42AM -0800, Andres Freund wrote:
> > Why do we need that rc variable? Don't we normally get away with (void)
> > write(...)?
>
> My compiler complains about that. :/
>
>
On Sat, Feb 25, 2023 at 11:28:25AM -0800, Nathan Bossart wrote:
> On Sat, Feb 25, 2023 at 11:07:42AM -0800, Andres Freund wrote:
>> I think the much more interesting assertion here would be to check that
>> MyProc->pid equals the current pid.
>
> I don't mind changing this, but why is this a more
On Sat, Feb 25, 2023 at 11:07:42AM -0800, Andres Freund wrote:
> On 2023-02-23 20:33:23 -0800, Nathan Bossart wrote:>
>> if (in_restore_command)
>> -proc_exit(1);
>> +{
>> +/*
>> + * If we are in a child process (e.g., forked by system() in
>> +
Hi,
On 2023-02-23 20:33:23 -0800, Nathan Bossart wrote:>
> if (in_restore_command)
> - proc_exit(1);
> + {
> + /*
> + * If we are in a child process (e.g., forked by system() in
> + * RestoreArchivedFile()), we don't want to call any
Hi,
On 2023-02-19 20:06:24 +0530, Robert Haas wrote:
> On Sun, Feb 19, 2023 at 2:45 AM Andres Freund wrote:
> > To me that seems even simpler? Nothing but the archiver is supposed to
> > create
> > .done files and nothing is supposed to remove .ready files without archiver
> > having created
Le 25/02/2023 à 16:40, Stéphane Tachoires a écrit :
Hi,
I'm not sure about the "child" -> "partition" change as it also
selects childs that are not partitions.
I'm more dubious about the --with-childs option, I'd rather have
--table-with-childs= and
--exclude-table-with-childs=. That will be
Hi,
On 2023-02-22 10:09:10 +0100, Peter Eisentraut wrote:
> On 20.02.23 20:48, Andres Freund wrote:
> > On 2023-02-20 19:43:56 +0100, Peter Eisentraut wrote:
> > > I don't think any callers try to copy a directory source, so the
> > > shutil.copytree() stuff isn't necessary.
> >
> > I'd like to
Hi,
On 2022-12-28 17:44:47 -0800, Andres Freund wrote:
> On 2022-12-28 18:35:38 -0600, Justin Pryzby wrote:
> > Since a few days ago, the windows/meson task has been spewing messages for
> > each tap
> > test:
> >
> > | Unknown TAP version. The first line MUST be `TAP version `. Assuming
> >
so 25. 2. 2023 v 18:13 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > so 25. 2. 2023 v 17:57 odesílatel Tom Lane napsal:
> >> Pavel Stehule writes:
> >>> -numeric(PG_FUNCTION_ARGS)
> >>> +numeric(PG_FUNCTION_ARGS)
>
> >> Sadly, pgindent will just put that back, because it
vcregress's installcheck_internal has "--encoding=SQL_ASCII --no-locale"
hardcoded. It's been like that for a long time, for no good reason that
I can see. The practical effect is to make it well nigh impossible to
run the regular regression tests against any other encoding/locale. This
in
Pavel Stehule writes:
> so 25. 2. 2023 v 17:57 odesílatel Tom Lane napsal:
>> Pavel Stehule writes:
>>> -numeric(PG_FUNCTION_ARGS)
>>> +numeric(PG_FUNCTION_ARGS)
>> Sadly, pgindent will just put that back, because it knows that "numeric"
>> is a typedef.
> Is it possible to rename
Noel Grandin writes:
> OK, so it seems like so far my design is not far off the PostgreSQL design
> (which is very comforting).
> I wonder if the difference is in the client<->server protocol.
That could be a piece of the puzzle, yeah.
> Does PostgreSQL hold the transaction open until the
so 25. 2. 2023 v 17:57 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > -numeric(PG_FUNCTION_ARGS)
> > +numeric(PG_FUNCTION_ARGS)
>
> Sadly, pgindent will just put that back, because it knows that "numeric"
> is a typedef.
>
Is it possible to rename this function?
>
>
Pavel Stehule writes:
> -numeric(PG_FUNCTION_ARGS)
> +numeric(PG_FUNCTION_ARGS)
Sadly, pgindent will just put that back, because it knows that "numeric"
is a typedef.
regards, tom lane
Hi,
I'm not sure about the "child" -> "partition" change as it also selects
childs that are not partitions.
I'm more dubious about the --with-childs option, I'd rather have
--table-with-childs= and --exclude-table-with-childs=.
That will be clearer about what is what.
I'm working on that, but
On Sat, Feb 25, 2023, at 7:31 AM, Tomas Vondra wrote:
> On 2/24/23 20:18, Justin Pryzby wrote:
> > This is a draft patch - review is welcome and would help to get this
> > ready to be considererd for v16, if desired.
> >
> > I'm going to add this thread to the old CF entry.
> >
On Fri, Feb 24, 2023 at 11:02:14PM -0600, Justin Pryzby wrote:
> I have some fixes (attached) and questions while polishing the patch for
> zstd compression. The fixes are small and could be integrated with the
> patch for zstd, but could be applied independently.
One more -
>> Could things be done in a more stable way? For example, imagine that
>> we have an extra Query field called void *private_data that extensions
>> can use to store custom data associated to a query ID, then we could
>> do something like that:
>> - In the post-analyze hook,
Hi
diff --git a/src/backend/utils/adt/numeric.c
b/src/backend/utils/adt/numeric.c
index a83feea396..12c6548675 100644
--- a/src/backend/utils/adt/numeric.c
+++ b/src/backend/utils/adt/numeric.c
@@ -1233,7 +1233,7 @@ numeric_support(PG_FUNCTION_ARGS)
* scale of the attribute have to be applied
Thanks!
On Fri, Feb 24, 2023 at 2:16 PM Tom Lane wrote:
>
> CK Tan writes:
> > Isn't it true that pfree() will never be called by PG_FREE_IF_COPY?
>
> No. You're forgetting the possibility that PG_GETARG_NUMERIC will
> have to de-toast a toasted input. Granted, numerics are seldom
> going to
On 2/24/23 22:07, Heikki Linnakangas wrote:
> I had a quick look at just the preliminary cleanup patches:
>
>> 0001-BRIN-bloom-cleanup-20230218.patch
>
> Looks good to me
>
>> 0002-BRIN-minmax-multi-cleanup-20230218.patch
>
> Looks good, although it would feel more natural to me to do it the
On 25 February 2023 00:50:30 EET, Stephen Frost wrote:
>Thanks for reviewing! Comments added and updated the commit message.
>
>Unless there's anything else, I'll push this early next week.
s/capture portal/captive portal/. Other than that, looks good to me.
- Heikki
On 2/24/23 20:18, Justin Pryzby wrote:
> This is a draft patch - review is welcome and would help to get this
> ready to be considererd for v16, if desired.
>
> I'm going to add this thread to the old CF entry.
> https://commitfest.postgresql.org/31/2888/
>
Thanks. Sadly cfbot is unhappy - the
On Tue, Feb 21, 2023 at 7:55 PM Önder Kalacı wrote:
>
>>
>> I think this overhead seems to be mostly due to the need to perform
>> tuples_equal multiple times for duplicate values. I don't know if
>> there is any simple way to avoid this without using the planner stuff
>> as was used in the
On Sat, 25 Feb 2023 at 08:33, Tom Lane wrote:
> Yeah, Postgres has an analogous kind of problem. Our standard way to
> use "large objects" is to store their identifying OIDs in tables,
>
...
> and in particular they can *not* close the transaction that read the
> OID if they'd like to read a
On Sat, Feb 25, 2023 at 02:58:36PM +0900, Michael Paquier wrote:
> On Fri, Feb 24, 2023 at 08:54:00PM +, Imseih (AWS), Sami wrote:
> > I think the only thing to do here is to call this out in docs with a
> > suggestion to increase pg_stat_statements.max to reduce the
> > likelihood. I also
41 matches
Mail list logo
