James Coleman writes:
> On Sat, Jan 20, 2024 at 12:59 PM Tom Lane wrote:
>> A HINT if the bogus column name (1) matches the relation name and
>> (2) is field-qualified seems plausible to me. Then it's pretty
>> likely to be a user misunderstanding about whether to write
le-less test for that case.
I thought about using current_user or the like as a stable comparison
value, but that introduces some doubt about what the collation would
be. That test seems cheap enough as-is, since it's handling only a
tiny amount of data.
Committed.
regards, tom lane
us column name (1) matches the relation name and
(2) is field-qualified seems plausible to me. Then it's pretty
likely to be a user misunderstanding about whether to write the
relation name.
regards, tom lane
at to do here.
(Unsurprisingly, jsonb_path_exists acts similarly.)
BTW, jsonb_path_query_array and jsonb_path_query_first seem to
take both types of path, like jsonb_path_query, so ISTM they need
docs changes too.
regards, tom lane
e index.
>
You sure about that? It would surprise me if we could effectively use
a not-equal condition with an index. If it is only == that works,
then the preceding statement seems sufficient.
regards, tom lane
post-11.0, but I kinda doubt we
would have back-patched it.
regards, tom lane
hese tags be things people would be likely
to have bookmarked?
regards, tom lane
ory context reset to clean things up.
regards, tom lane
I wrote:
> I experimented with
> SELECT '
> ... multiline json value ...
> ' AS json
> \gexec
> but that didn't seem to work either. Anybody have a better idea?
Oh, never mind, \gset is what I was reaching for. We can make
it work with that.
regards, tom lane
. multiline json value ...
' AS json
\gexec
but that didn't seem to work either. Anybody have a better idea?
regards, tom lane
is enough for this.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/149c5c2f-4267-44e3-a177-d1fd24c53f6d%40universite-paris-saclay.fr
From 30d4c77641876db2ffd81a188bd2e41856a7a99e Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Fri, 19 Jan 2024 14:16:09 -05
proved the readability. I'd still
rather keep the newline-assembly code together as much as possible.
Maybe we should do the search part before we build any of newline?
regards, tom lane
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index ac409b0006..6a62
construction and inspection a bit, but
it would avoid building an enormous lot of infrastructure to deal
with transitioning to a not-upward-compatible definition.
regards, tom lane
-picky hardware, or else
result in space wastage if we were careful to MAXALIGN() everywhere.
(Which we should have been, but I don't care to bet on it.) A lot of
people would be sad if their indexes got noticeably bigger when they
weren't getting anything out of that.
regards, tom lane
to-table?
Trying to distinguish a file name from a table name without any other
context seems impossible.
regards, tom lane
se in a SET command.
regards, tom lane
to support multiple matches
I doubt that's sufficient.
regards, tom lane
Alvaro Herrera writes:
> Hmm, how about raising an error if multiple options are given targetting
> the same GUC?
I don't see any reason to do that. The underlying configuration
files don't complain about duplicate entries, they just take the
last setting.
regard
or that is presented, should we accept it?
I'm having a hard time believing that this requirement is common
enough to justify more than a microscopic addition of complexity.
This whole area is devilishly complicated already, and I can think of
a bunch of improvements that I'd rate as more worthy of developer
effort than this.
regards, tom lane
D (CURRENT_DATE <
'1997-04-10'::date))
(2 rows)
I'd suggest losing the temp table and just coding tests like these.
regards, tom lane
diff --git a/src/backend/utils/adt/rangetypes.c b/src/backend/utils/adt/rangetypes.c
index d99b00b590..2d94a6b877 100644
--- a/src/bac
Robert Haas writes:
> On Mon, Jan 15, 2024 at 2:28 PM Tom Lane wrote:
>> I'm reasoning by analogy to array types, which are automatically
>> created and automatically updated to keep the same ownership
>> etc. properties as their base type. To the extent that multiran
rying to stop at.
regards, tom lane
Robert Haas writes:
> On Mon, Jan 15, 2024 at 1:27 PM Tom Lane wrote:
>> That's pretty broken, isn't it? joe would own the multirange if he'd
>> created the range to start with. Even if you think the ownerships
>> ideally should be separable, this behavior causes exis
, so maybe I can do
> something to help at least with that part of it.
This is indeed on my to-do list, and I have every intention of
getting to it before the end of the month. But if you want to
help push things along, feel free.
regards, tom lane
David Geier writes:
> On 12/27/23 18:38, Tom Lane wrote:
>> Hmm. It seems odd that if an extension defines a type, the type is
>> listed as a member of the extension but the array type is not.
>> That makes it look like the array type is an externally-created
>> t
.
regards, tom lane
r real-world behavior?
regards, tom lane
in pg_depend which doesn't.
So that put a damper on my enthusiasm for the idea.
regards, tom lane
ck, then it can save several
> CPU cycles.
Meh, I'd just as soon not add the additional dependency/risk of bugs.
This is an expensive and seldom-taken code path, so I don't think
shaving a few cycles is really important.
regards, tom lane
If that function grows any more complexity
then we could think about using PG_TRY.
regards, tom lane
is just breaking first because it is using a newer
> version.
Yeah, I have nothing newer than 1.17 here either.
Time for a bug report to IO::Tty's authors, I guess.
regards, tom lane
Nathan Bossart writes:
> On Wed, Dec 20, 2023 at 06:47:44PM -0500, Tom Lane wrote:
>> +char *cmdEnd = psprintf(" OWNER TO %s",
>> fmtId(te->owner));
>> +
>> +IssueCommandPerBlob(AH, te, "ALTER LARGE OBJ
with or without
--enable-llvm --- the process size stays quite stable according
to "top". I wonder if you are using some extension that's
contributing to the problem.
regards, tom lane
I remembered systable_recheck_tuple,
which is meant for exactly this purpose. So v4 attached.
regards, tom lane
diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c
index c0591cffe5..0dcd45d2f0 100644
--- a/src/backend/utils/cache/catcache.c
+++ b/src/b
o do about this.
regards, tom lane
g is adding a random failure about 0.1% of
the time in USE_ASSERT_CHECKING builds --- that's intellectually
ugly for sure, but doing better seems like way more work than
it's worth.
regards, tom lane
diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils
Without getting into opinions on whether List is a good abstraction,
I'm -1 on this idea. It would be a large amount of code churn, with
attendant back-patching pain, and I just don't see that there is
much to be gained.
regards, tom lane
cleaner way to make this check?
Also, I'm pretty dubious that GetNonHistoricCatalogSnapshot rather
than GetCatalogSnapshot is the right thing, because the catcaches
use the latter.
regards, tom lane
entially creating conflicts with the copied
> data files."
"avoid logical replication workers running" still seems like shaky
grammar. Perhaps s/avoid/avoid having/, or write "to prevent logical
replication workers from running ...".
Also perhaps s/would/could/.
Otherwise +1
regards, tom lane
Michael Paquier writes:
> I am wondering if we'd better backpatch all that, TBH.
Seems like a good idea to me.
regards, tom lane
ion about how wide the tabs are.
But I'm not touching that question today.
regards, tom lane
Laurenz Albe writes:
> On Mon, 2024-01-08 at 15:48 -0500, Tom Lane wrote:
>> Is this enough of a bug to deserve back-patching? I'm not sure.
> I like the patch, but I wouldn't back-patch it. I'd call the current
> behavior a slight inconsistency rather than an outright b
Bharath Rupireddy writes:
> On Wed, Jan 10, 2024 at 12:54 PM Tom Lane wrote:
>> Yeah. I'm not quite sure what's a good way to make this work, but
>> it seems like having "make check-world" always invoke it would not
>> be desirable. Making that conditional on an
Michael Paquier writes:
> On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote:
>> So that leads to the conclusion that I wouldn't want an automatic
>> pgindent check to happen during "make all" or "make check", because
>> I want those things
ng "make all" or "make check", because
I want those things to succeed before I consider pgindent'ing.
Maybe it's okay to include it as part of check-world, but I'm
not quite sure about that either.
regards, tom lane
Bharath Rupireddy writes:
> On Wed, Jan 10, 2024 at 10:00 AM Tom Lane wrote:
>> Maybe. I bet just bumping up the constant by 2X or 4X or so would get
>> most of the win for far less work; it's not like adding a few more
>> LWLocks is expensive. But we need some evide
about what to set it to.
regards, tom lane
es of
PATH_PARAM_BY_PARENT, and I bet there are more dependencies elsewhere.
So I'm not sure about the value of asserting it only here.
In short I'm inclined to apply v3 as-is.
regards, tom lane
expert here, but it does seem like the same argument
applies.
regards, tom lane
ld go from a mask operation to a full integer divide. We are
unlikely to consider that on the basis of an unsupported assertion
that there's a performance gain under unspecified conditions.
Even with data to justify a change, I think it'd make a lot more sense
to just raise the constant value.
ten that patch yet.
regards, tom lane
sional contributors
are even less likely to be able to cope with this.
In short, I don't think that putting this into CI is the answer.
Putting it into committers' standard workflow is a better idea,
if we can get all the committers on board with that.
regards, tom lane
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> Maybe it would work to have both
>> pg_get_serial_sequence(table text, column text) -> text
>> pg_get_serial_sequence(table regclass, column text) -> regclass
> I think it would be more corr
er
couldn't choose between these candidates.
regards, tom lane
Robert Haas writes:
> On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote:
>> I think we're talking at cross-purposes. What I was wondering about
>> (at least further down in the thread) was whether we shouldn't be
>> checking *both* the "real" and the "paren
I wrote:
> However, the patch looks a little incomplete: you did not remove
> fetching of all of the now-unneeded values from the SQL queries.
Oh, scratch that, I now see that we already did that query
optimization.
regards, tom lane
quot;if" branches. This patch removes the
> rest of the unneeded code.
Hm, you're right, we can depend on pg_get_triggerdef in all cases now.
However, the patch looks a little incomplete: you did not remove
fetching of all of the now-unneeded values from the SQL queries.
regards, tom lane
"Tristan Partin" writes:
> On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote:
>> +(isascii((unsigned char)
>> mybuf.data[mybuf.len - 1]) &&
>> + isspace((unsi
Robert Haas writes:
> On Sat, Jan 6, 2024 at 4:08 PM Tom Lane wrote:
>> The argument for the patch as proposed is that we should make the
>> mergejoin and hashjoin code paths do what the nestloop path is doing.
>> However, as I replied further down in that other threa
that logic into psql_scan_slash_option.
Is this enough of a bug to deserve back-patching? I'm not sure.
regards, tom lane
[1]
https://www.postgresql.org/message-id/CAEs%3D6D%3DnwX2wm0hjkaw6C_LnqR%2BNFtnnzbSzeZq-xcfi_ooKSw%40mail.gmail.com
diff --git a/src/bin/psql/command.c
Richard Guo writes:
> On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote:
>> Thanks for the report! I guess we need something like the attached.
> +1.
Pushed, thanks for looking at it.
>> I'm surprised that this hasn't been noticed before; was the case
>> really unreach
lid 1
> starting from f7816aec2.
Thanks for the report! I guess we need something like the attached.
I'm surprised that this hasn't been noticed before; was the case
really unreachable before?
regards, tom lane
diff --git a/src/backend/optimizer/util/relnode.c b/sr
Robert Haas writes:
> On Fri, Jan 5, 2024 at 4:36 PM Tom Lane wrote:
>> I don't think I believe this code change, let alone any of the
>> explanations for it. The point of these Asserts is to be sure that
>> we don't form an alleged parameterization set t
rhaps after adding a
nullingrel bit that references the grouping RTE). If a grouping
column is an expression, we might be able to replace the reference
Vars with PHVs as you've done here ... but I think we need the
parser infrastructure fixed first.
regards, tom lane
[1]
https://
Returns a PGresult pointer representing
+ the result of the ALTER USER command, or
+ a null pointer if the routine failed before issuing any command.
regards, tom lane
why when contemplating examples like
this. It's a little weird that "concat(test1.n, ...)" can evaluate
with a non-null value of test1.n in a row where test1.n alone would
evaluate as null. However, we've dug this hole for ourselves and now
we have to deal with the consequences.]
regards, tom lane
but I'm not quite convinced what the point of that is.
regards, tom lane
ut, applying parallelism within pg_restore for the
first kind and then using cross-database parallelism for the
rest. But that seems like a lot of complexity compared to the
possible win.
In any case I'd stay far away from using --section in pg_upgrade.
Too many moving parts there.
regards, tom lane
ents here.
regards, tom lane
Robert Haas writes:
> On Fri, Jan 5, 2024 at 11:53 AM Tom Lane wrote:
>> So my thought was that this should be implemented as an (unchangeable)
>> flag bit for a GUC variable, GUC_PROTOCOL_ONLY or something like that,
>> and then we would refuse SQL-based set attempts o
action with transactions.
regards, tom lane
aps not given the current calculation method,
but since it's a float4 there's at least a theoretical risk. Hence,
I adopted Jian's suggestion.
One other point is that examine_variable is capable of succeeding
on things that aren't Vars, so I thought the restriction to Vars
was inappropriate.
regards, tom lane
of just returning NULL when they don't find the name.
Right now, if NULL is returned, we end up passing the whole
string to parse_datatype, leading to unhelpful errors like
the one shown above. We could do better than that I think,
perhaps like "argument of %TYPE is not a known variable".
Robert Haas writes:
> On Thu, Jan 4, 2024 at 10:22 AM Tom Lane wrote:
>> We should be making an effort to ban coding patterns like
>> "return with spinlock still held", because they're just too prone
>> to errors similar to this one.
> I agree that we don't wa
that trying to take another
lock is far from the only bad thing that can happen if you're
not very conservative about what code can execute with a spinlock
held.
regards, tom lane
re-recent commits that seem like plausible explanations.
regards, tom lane
just how far back might gcc choose to do that unrolling?
Does the size of the loop body matter?)
regards, tom lane
nt to propose
a complete rewording, do so; but that's not "misspelling" territory.
regards, tom lane
Jeff Davis writes:
> Looks good to me.
Thanks for reviewing, will push shortly.
regards, tom lane
t and if so to what.
I'm not convinced that point is dispositive, but it's something
to consider.
regards, tom lane
good to
hear comments on that point from people who actually use it.
regards, tom lane
"Kumar, Sachin" writes:
>> On 11/12/2023, 01:43, "Tom Lane" > <mailto:t...@sss.pgh.pa.us>> wrote:
>> ... Maybe that
>> could be improved in future, but it seems like it'd add a
>> lot more complexity, and it wouldn't make life any better
. OTOH, maybe there's
no choice given than we need a different definition for Vector8 and
Vector32?
regards, tom lane
pped, but it is working
as designed and documented.
I fear your proposed patch is likely to break more things than it fixes.
In particular it looks like it would forget the existence of the
user's self-revocation altogether, even before the drop of the user.
regards, tom lane
edefs.list:2479
> error: src/tools/pgindent/typedefs.list: patch does not apply
Use patch(1). git-apply is extremely fragile.
regards, tom lane
) some comments. I assume it wasn't
intentional to leave two copies of the same comment block in
check_search_path().
regards, tom lane
diff --git a/src/backend/catalog/namespace.c b/src/backend/catalog/namespace.c
index 37a69e9023..465a4e40bc 100644
--- a/src/backend/catalog
recommend that while fixing the test, you stick in some
debugging elogs to verify when the dealloc calls actually happen
rather than assuming you predicted it correctly. I did it as
attached.
regards, tom lane
diff --git a/contrib/pg_stat_statements/pg_stat_statement
now.
I see it failed on my animal mamba, so I should be able to reproduce
it there. Will look.
regards, tom lane
with version-to-version ABI changes?
regards, tom lane
Jeff Davis writes:
> On Fri, 2023-12-29 at 13:38 -0500, Tom Lane wrote:
>> This is assuming facts not in evidence. Why would we want such a
>> thing?
> The problem came up during the binary_formats GUC discussion: it
> doesn't really make sense to change that with a SQ
e GUC model that should not be there. I do perceive that
there are things that could be protocol-level variables, but
trying to say they are a kind of GUC seems like it will create
more problems than it solves.
regards, tom lane
Heikki Linnakangas writes:
> On 29/12/2023 01:42, Tom Lane wrote:
>> I didn't stop to trace the details but I'm pretty sure this is why
>> you're getting the bogus extra projections shown in the 0005 patch.
> They're not bogus. With the patches, projecting away the junk col
r BeginInternalSubTransaction.
I haven't thought hard about what new test cases we might want to
add for this. It gets through check-world as is, meaning that
nobody has made any test cases exercising the previous restrictions
either. There might be more documentation work to be done, too.
if we change resjunk, we
don't need the replacement design to account for this bit.
regards, tom lane
pecially
not given the requirement to dump from older server versions.
(Conceivably we could just say that we won't dump stats from server
versions predating the introduction of this feature, but that's hardly
a restriction that supports doing this via a view.)
regards, tom lane
ifferent stack after
> longjmp()...).
+1, there's basically no hope of debugging this sort of problem
as things stand.
regards, tom lane
ght-through
reference implementation in libpq would help those authors.
So I don't think this is a strike against the patch; but the answer
to Peter's question has to be that this is just part of the solution.
regards, tom lane
Of course, fixing it like that leads to needing to change the
contents of pg_depend, so it wouldn't be back-patchable. But it
seems like the best way in the long run.
regards, tom lane
resented by pg_depend entries, but it's far from clear that it'll
never be an issue for stats.
So I think it needs to be more like the attached.
(I did use your test case verbatim.)
regards, tom lane
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 8
at a more realistic
case with moderate amounts of data in the blobs would make pg_dump
look better.
regards, tom lane
801 - 900 of 15280 matches
Mail list logo
