On Sat, May 31, 2025, at 23:56, Tom Lane wrote:
> "Joel Jacobson" writes:
>> Foreign key constraints created during CREATE EXTENSION
>> lack a pg_depend entry with deptype='e'.
>
> Why would it be a sensible thing for an extension to create a
> foreign-key constraint on table(s) that it didn't its
On 05/31/25 21:12, Tom Lane wrote:
> I think you're overthinking it. There is one round of dequoting
> and downcasing in the grammar, and after that a name is just a
> literal string. It's perfectly okay to just store that string and
> do exact comparisons to it against other names (which themsel
On Sat, May 31, 2025 at 01:26:14PM +0700, Daniil Davydov wrote:
> Not yet. I proceed from the assumption that if the temp_buffers
> parameter is set to a large value (some users set it to more than a
> gigabyte), then the vast majority of time is spent iterating through
> the local buffers.
> Thus,
Chapman Flack writes:
> On 05/31/25 19:55, Tom Lane wrote:
>> I'm not following that part?
> It's that ISO rule that identifiers match case-insensitively
> if they weren't quoted, case-sensitively if they were.
> We don't explicitly store in catalogs whether quoting was used.
> Clearly it must h
On 05/31/25 19:55, Tom Lane wrote:
> Chapman Flack writes:
>> SQL rules would also make its case-sensitivity dependent on faithfully
>> recovering whether it was delimited or not.
>
> I'm not following that part?
It's that ISO rule that identifiers match case-insensitively
if they weren't quoted
On Sat, May 31, 2025 at 5:06 PM Nikolay Samokhvalov wrote:
> On Thu, May 29, 2025 at 11:56 AM Sami Imseih wrote:
>
>> It turns out that 1722d5eb05d8e reverted 525392d5727f, which
>> made CachedPlan available in QueryDesc and thus
>> available to pgss_ExecutorEnd.
>>
>> So now we have to make Cac
On Thu, May 29, 2025 at 11:56 AM Sami Imseih wrote:
> It turns out that 1722d5eb05d8e reverted 525392d5727f, which
> made CachedPlan available in QueryDesc and thus
> available to pgss_ExecutorEnd.
>
> So now we have to make CachedPlan available to QueryDesc as
> part of this change. The reason t
Chapman Flack writes:
> generic_option_name is a ColLabel, therefore a fully general SQL identifier.
> But a command like CREATE FOREIGN DATA WRAPPER w ... OPTIONS ("a=b" 'c=d')
> stores {a=b=c=d} in fdwoptions, from which the original intent can't be
> recovered.
Ugh.
> Should generic_option_n
"Joel Jacobson" writes:
> Foreign key constraints created during CREATE EXTENSION
> lack a pg_depend entry with deptype='e'.
Why would it be a sensible thing for an extension to create a
foreign-key constraint on table(s) that it didn't itself create?
(If it did create them, the indirect dependen
Hi hackers,
Foreign key constraints created during CREATE EXTENSION
lack a pg_depend entry with deptype='e'.
Looking at the code, I found that CreateConstraintEntry() in
src/backend/catalog/pg_constraint.c does not call
recordDependencyOnCurrentExtension(), unlike most other CREATE functions.
Th
My attention happened to be drawn to plpython's PLy_traceback()
function, and I noted a couple of things that sure seem like bugs.
First, there's this bit:
e_type_o = PyObject_GetAttrString(e, "__name__");
e_module_o = PyObject_GetAttrString(e, "__module__");
if (e_type_o)
On Sat, May 31, 2025 at 2:52 PM Nikolay Samokhvalov wrote:
> I was just involved in a DR case, where we needed to change system ID in
> control data, and noticed that there is no such capability, officially – so
> I thought, it would be good to have it
>
> the attached patch adds a new -s / --sys
hi hackers,
I was just involved in a DR case, where we needed to change system ID in
control data, and noticed that there is no such capability, officially – so
I thought, it would be good to have it
the attached patch adds a new -s / --system-identifier option to
pg_resetwal that allows users to
Thomas Munro writes:
> It's slightly tricky to get smgr to behave differently because of the
> contents of a system catalogue!
The mere thought makes me blanch. I'm okay with the GUC part,
but I do not think we should put in 0002 --- the odds of
causing serious problems greatly outweigh the valu
On Thu, 2025-05-08 at 05:23 +0700, John Naylor wrote:
> Right. That's also true of PowerPC -- perhaps that's a different team
> than yours?
indeed that's another team. I can ping them but there is not much more
I can do.
> This case is a bit different, since Arm can compute hardware CRC on
> any
On 5/31/25 16:00, Thomas Munro wrote:
> On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou wrote:
>> All I'm saying is that this is a regression for PostgreSQL users that keep
>> tablespaces on compressed Btrfs. What could be done from postgres, is to
>> provide a runtime setting for avoiding fal
Or for a completely different approach: I wonder if ftruncate() would
be more efficient on COW systems anyway. The minimum thing we need is
for the file system to remember the new size, 'cause, erm, we don't.
All the rest is probably a waste of cycles, since they reserve real
space (or fail to) la
Hi,
On Sat, May 31, 2025 at 7:41 PM Fujii Masao wrote:
>
> Here are a few review comments on the patch:
>
> + for (j = 0; j < nforks; j++)
> {
> - InvalidateLocalBuffer(bufHdr, true);
> + if ((buf_state & BM_TAG_VALID) &&
>
On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou wrote:
> All I'm saying is that this is a regression for PostgreSQL users that keep
> tablespaces on compressed Btrfs. What could be done from postgres, is to
> provide a runtime setting for avoiding fallocate(), going instead through
> the old c
On 2025/05/31 15:26, Daniil Davydov wrote:
Hi,
On Sat, May 31, 2025 at 7:49 AM Michael Paquier wrote:
On Fri, May 30, 2025 at 06:01:16PM +0700, Daniil Davydov wrote:
For now we fully scan local buffers for each fork of the temporary
relation that we want to truncate (in order to drop its
On Wed, 28 May 2025 at 11:37, Tender Wang wrote:
>
> Dean Rasheed 于2025年5月28日周三 18:26写道：
>>
>> Unless there are any further comments, I plan to commit it in a day or so.
>
> I don't have any other comments. It looks good for me.
>
Thanks for looking. I have committed this now.
Regards,
Dean
I realized two smallish commitfest app improvements were merged but
not deployed yet for quite some time.
1. There's now a similar summary at the top of the "Personal
Dashboard" page, as is on regular commitfest pages. Thanks to Akshat
Jaimini.
2. Selecting the committer for a committed patch from
On Fri, May 30, 2025 at 2:02 AM Tom Lane wrote:
> Finally, here's a minimalistic version of the original v1-0001
> patch that I think we could safely apply to fix the DirectModify
> problem in the back branches. I rejiggered it to not depend on
> inventing MemoryContextUnregisterResetCallback, so
23 matches
Mail list logo
