On Tue, Jul 15, 2025 at 11:20 PM Alexander Kukushkin
wrote:
> However, we regularly hear from many different customers that they *don't
> control queries* sent by application or *can't modify these queries*.
> Such kinds of workloads are also not that uncommon and this change makes
> it impossibl
On Wed, 16 Jul 2025 at 01:39, Michael Paquier wrote:
>
> > create schema s1;
> > create table s1.t as select id from generate_series(1, 10) as id;
> > create schema s2;
> > create table s1.t as select id from generate_series(1, 100) as id;
>
> I suspect that you mean s2.t and not s1.t here.
>
On Tue, Jul 15, 2025 at 04:48:05PM +0200, Alexander Kukushkin wrote:
> I totally understand the wish to make pg_stat_statements useful for
> workloads that create/drop a ton of temporary tables.
> However, when pursuing this goal we impacted other types of totally valid
> workloads when tables with
Hi,
I totally understand the wish to make pg_stat_statements useful for
workloads that create/drop a ton of temporary tables.
However, when pursuing this goal we impacted other types of totally valid
workloads when tables with the same name exist in different schemas.
Example:
create schema s1;
cr
Hi,
On Fri, 6 Jun 2025 at 08:30, Peter Eisentraut wrote:
>
> On 05.06.25 12:42, Thomas Munro wrote:
> > I think on your C11 thread I might have been confused about that,
> > since there was an implication that 2019 might support ,
> > but it looks like 2019 added language stuff while 2022 added t
On 05.06.25 12:42, Thomas Munro wrote:
I think on your C11 thread I might have been confused about that,
since there was an implication that 2019 might support ,
but it looks like 2019 added language stuff while 2022 added the
library stuff. But yeah, given your proposal that MSVC 2019 should be
On Thu, Jun 5, 2025 at 8:48 PM Nazir Bilal Yavuz wrote:
> > Hmm, for the purposes of [0], I think it might be better to keep the
> > image at VS 2019 for now. Unless there are specific reasons why VS 2022
> > would be of use now?
>
> Thomas was thinking of trying some new APIs which are available
Hi,
On Thu, 5 Jun 2025 at 11:27, Peter Eisentraut wrote:
>
> On 05.06.25 10:04, Nazir Bilal Yavuz wrote:
> > Thomas Munro off-list mentioned that the Windows CI image is actually
> > running on Server 2022, even though the task name still refers to
> > Server 2019. He also suggested upgrading the
On 05.06.25 10:04, Nazir Bilal Yavuz wrote:
Thomas Munro off-list mentioned that the Windows CI image is actually
running on Server 2022, even though the task name still refers to
Server 2019. He also suggested upgrading the compiler from Visual
Studio 2019 to Visual Studio 2022.
Some of the ta
Andres'
pg-vm-images repository (where the CI images are built). This VS 2022
image passes all tests for both MinGW [2] and Meson & Ninja [2]. Once
it's merged, the CI images will automatically start using the VS 2022
compiler.
Two patches are attached, the first one is for fixing se
On Wed, Apr 16, 2025 at 03:25:19PM -0700, Michael Paquier wrote:
> If anybody objects about the points getting renamed here, please let
> me know.
Applied this one as 114f7fa81c72.
--
Michael
signature.asc
Description: PGP signature
On Fri, Jan 3, 2025 at 8:44 AM Robert Haas wrote:
> > Actually, I noticed that we are failing to honor that in the places
> > where we inject "*SELECT*" and "*SELECT* %d" names, because that
> > code puts those names into RTE->alias not only RTE->eref
On Mon, Apr 14, 2025 at 11:14:59AM +, Hayato Kuroda (Fujitsu) wrote:
>> Anyway, would you like to propose a patch for the documentation?
>
> Sure, I did. Please see [1].
>
> [1]:
> https://www.postgresql.org/message-id/OSCPR01MB14966E14C1378DEE51FB7B7C5F5B32%40OSCPR01MB14966.jpnprd01.prod.ou
Dear Michael,
> > I have no objections for the patch, but I feel there are no concrete naming
> > rules
> > (I confused while creating patches).
>
> There has been a sort of implied rule in the code to use lower
> characters, with terms separated by dashes. Perhaps we could make
> that more off
On Mon, Apr 14, 2025 at 08:13:44AM +, Hayato Kuroda (Fujitsu) wrote:
> I have no objections for the patch, but I feel there are no concrete naming
> rules
> (I confused while creating patches).
There has been a sort of implied rule in the code to use lower
characters, with terms separated by
Dear Michael,
> 93bc3d75d8e1 has introduced a couple of new injection points, but
> these don't follow the convention in-place where points are named
> more-or-less-like-that. Please find attached a patch to make all
> these more consistent.
I have no objections for the patch, but I feel there a
Hi all,
(well, Andres)
93bc3d75d8e1 has introduced a couple of new injection points, but
these don't follow the convention in-place where points are named
more-or-less-like-that. Please find attached a patch to make all
these more consistent.
Thoughts or comments?
--
Michael
diff --git a/src/bac
On Sat, Mar 22, 2025 at 10:43:00AM +0100, Christoph Berg wrote:
> Are we at the point where the patch is already Ready for Committer?
I'll think a bit more about how to document all that. Anyway, yes,
I'm OK with the per-field custom_query_jumble, so let's move on with
that, so I will do somethin
uld not write to ssl keylog file %s: %s
>
> However, I believe our convention is to quote file names in such messages.
Thanks for the report, I'll get it fixed.
> - A WARNING message in `fd.c` seems worth fixing (0002).
Thi is an elog() and not an error intended to be common for users, so
ion is to quote file names in such messages.
The attached patch 0001 fixes this issue.
While working on this, I found a few other instances of the same
issue:
- A WARNING message in `fd.c` seems worth fixing (0002).
- Two DEBUG2 messages in `xlog.c` seem less important to fix (0003).
- I don
Hi Rustam,
> Hi Aleksander,
> I have reviewed your patch. It looks good to me.
>
> Kindest regards.
> Rustam Allakov
>
> The new status of this patch is: Ready for Committer
Thanks for testing!
Here is the rebased patch.
--
Best regards,
Aleksander Alekseev
v5-0001-Always-use-long-SLRU-segme
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Aleksander,
I have reviewed your patch. It looks good to
On Tue, Mar 25, 2025 at 07:56:29PM -0500, Sami Imseih wrote:
> FWIW, the pg_stat_statements docs in a few places refer to
> queries that may look different but have the same meaning
> as “semantically equivalent”, this is why I used the same
> terminology here. But, I have no issue with the sim
> If I get the difference right, semantically would apply to concepts
> related to linguistics, but that's not what we have here, so you are
> using a more general term.
FWIW, the pg_stat_statements docs in a few places refer to
queries that may look different but have the same meaning
as “sem
ude/nodes/parsenodes.h
index 23c9e3c5abf2..df331b1c0d99 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -1050,8 +1050,13 @@ typedef struct RangeTblEntry
*/
/* user-written alias clause, if any */
Alias *alias pg_node_attr(query_jumble_ignore);
- /* expanded refer
x27;t read very smoothly:
+ * Expanded reference names. This uses a custom query jumble function so
+ * as the table name is included in the computation, not its list of
+ * columns.
Perhaps better
+ * Expanded reference names. This uses a custom query jumble function so
+
emain a bit more
evasive, with "if they reference *for example* a function that was
dropped and recreated between the executions of the two queries".
Note that for DDLs, like CREATE TABLE, we also group entries with
identical relation names, so we are kind of in line with the patch,
not
> > Attached is the second one, with more tests coverage with attribute
> > aliases (these being ignored exists in stable branches, but why not
> > while on it) and table aliases, and the fixes for the issues pointed
> > out by Christoph. I'll double-check all that again tomorrow. Please
> > find
Re: Michael Paquier
> Attached is the second one, with more tests coverage with attribute
> aliases (these being ignored exists in stable branches, but why not
> while on it) and table aliases, and the fixes for the issues pointed
> out by Christoph. I'll double-check all that again tomorrow. Plea
> In my experience these often not work well with pg_stat_statements today
> because
> of their own bloat problem, just like with temp tables. You quickly have way
> too many
> unique entries, and your query text file accumulates a lot of duplicative
> entries
> (since the same query text gets r
typedef struct RangeTblEntry
*/
/* user-written alias clause, if any */
Alias *alias pg_node_attr(query_jumble_ignore);
- /* expanded reference names */
- Alias *eref pg_node_attr(query_jumble_ignore);
+
+ /*
+ * Expanded reference names. This uses a custom query jumble function so
+ * as the
On Mon, Mar 24, 2025 at 8:51 PM Michael Paquier wrote:
> On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > > select * from foo s1;
> > > select * from foo s2;
> >
> > ah, thanks for pointing this out. Not as good of a workaround as
> > a comment since one must change aliases, but a
On Tue, Mar 25, 2025 at 01:17:22AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
> >> 2. Tools that are not entitled to set the value of the GUC are forced
> >> to be prepared to cope with any setting. That can be anywhere from
> >>
Julien Rouhaud writes:
> On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>> 2. Tools that are not entitled to set the value of the GUC are forced
>> to be prepared to cope with any setting. That can be anywhere from
>> painful to impossible.
> Didn't that ship already sailed in pg14 wh
Hi,
On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>
> I'm not opining one way or the other on whether squashing an IN list
> is desirable. My point is that a GUC is a poor way to make --- or
> really, avoid making --- such decisions. The reasons we took away
> from previous experimen
> Exactly. Like Tom I'm not really worried about the proposal, but of
> course I could prove to be wrong. I am ready to assume that bloat in
> pgss entries caused by temp tables is a more common case.
I ran installcheck-parallel with the patch and without the patch
3x, and the reduction in pg_s_
Sami Imseih writes:
>> I don't like that GUC and I would not like this one either. We
>> learned years ago that GUCs that change query semantics are a bad
>> idea, but apparently now we have hackers who need to relearn that
>> lesson the hard way.
> query_id_squash_values has a much weaker argum
On Mon, Mar 24, 2025 at 10:30:59PM -0500, Sami Imseih wrote:
>> Sami Imseih writes:
>>> I agree that some may want stats to merge for the same tables,
>>> and others may not. I will suggest this with some hesitation, but why not
>>> make this behavior configurable via a GUC?
>>> We recently introd
On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > select * from foo s1;
> > select * from foo s2;
>
> ah, thanks for pointing this out. Not as good of a workaround as
> a comment since one must change aliases, but at least there is
> a workaround...
Exactly. Like Tom I'm not reall
On Mon, Mar 24, 2025 at 04:41:35PM +0100, Christoph Berg wrote:
> Re: Michael Paquier
>> +++ b/src/backend/nodes/queryjumblefuncs.c
>> @@ -33,6 +33,7 @@
>> #include "postgres.h"
>>
>> #include "access/transam.h"
>> +#include "catalog/namespace.h"
>
> No longer needed.
Indeed.
>> +++ b/contri
> Sami Imseih writes:
> > I agree that some may want stats to merge for the same tables,
> > and others may not. I will suggest this with some hesitation, but why not
> > make this behavior configurable via a GUC?
> > We recently introduced query_id_squash_values for controlling
> > the merge of a
Sami Imseih writes:
> I agree that some may want stats to merge for the same tables,
> and others may not. I will suggest this with some hesitation, but why not
> make this behavior configurable via a GUC?
> We recently introduced query_id_squash_values for controlling
> the merge of an IN list, m
> select * from foo s1;
> select * from foo s2;
ah, thanks for pointing this out. Not as good of a workaround as
a comment since one must change aliases, but at least there is
a workaround...
> As against this, there is probably also a set of people who would
> *like* identical queries on identic
Sami Imseih writes:
> For example, I have seen users add comments to SQLs to differentiate
> similar SQLs coming from different tenants. This patch makes this no longer a
> somewhat decent workaround to overcome the fact that pg_stat_statements
> does not track schemas or search path.
Well, the
> So your idea to use the relation name in eref while skipping the
> column list looks kind of promising. Per se the attached. Thoughts?
I feel really uneasy about this behavior becoming the default.
I can bet there are some users which run common queries across
different schemas ( e.g. multi-te
idea; for starters, there is nothing
preventing overlap between the set of GUC names and the set of
table names.
Perhaps it is worth inventing bespoke syntax for this --- I doubt it,
but others might think differently --- but please let's not overload
SHOW.
regards, tom lane
In discussing vacuum_truncate_set it occurs to me there is no SQL way for
someone to easily view the current setting (or unset status) of a
reloption. Seems like we could modify SHOW to cover this use case. It is
mostly redundant with \d+ which already distinguishes unset and set options
by displ
Re: Michael Paquier
> So your idea to use the relation name in eref while skipping the
> column list looks kind of promising. Per se the attached. Thoughts?
Makes sense to me, thanks for digging into it.
> +++ b/src/backend/nodes/queryjumblefuncs.c
> @@ -33,6 +33,7 @@
> #include "postgres.h"
>
On Sat, Mar 22, 2025 at 09:04:19PM -0400, Tom Lane wrote:
> Right. I'm arguing that that's good. The proposed patch already
> obscures the difference between similar table names in different
> (temp) schemas, and I'm suggesting that taking that a bit further
> would
On Sat, Mar 22, 2025 at 12:24:43PM -0400, Tom Lane wrote:
> I experimented with this trivial fix (shown in-line to keep the cfbot
> from thinking this is the patch-of-record):
>
> What's happening there is that there's an ALTER TABLE ADD COLUMN in
> the test, so the executions after the first one
tch already
obscures the difference between similar table names in different
(temp) schemas, and I'm suggesting that taking that a bit further
would be fine.
Note that if the tables we're considering don't have identical
rowtypes, the queries would likely jumble differently anyway
due to di
y
/* user-written alias clause, if any */
Alias *alias pg_node_attr(query_jumble_ignore);
/* expanded reference names */
- Alias *eref pg_node_attr(query_jumble_ignore);
+ Alias *eref;
RTEKind rtekind;/* see above */
@
Michael Paquier writes:
> On Sat, Mar 22, 2025 at 10:43:00AM +0100, Christoph Berg wrote:
>> Are we at the point where the patch is already Ready for Committer?
> I'll think a bit more about how to document all that. Anyway, yes,
> I'm OK with the per-field custom_query_jumble, so let's move on
Re: To Michael Paquier
> > >> +#define JUMBLE_CUSTOM(nodetype, item) \
> > >> +_jumble##nodetype##_##item(jstate, expr, expr->item)
> >
> > In this one, I want to mean that we require a custom per-field
> > function to look like that:
> > _jumbleNodefoo_field(JumbleState *jstate, NodeFoo *
Re: Michael Paquier
> >> + * Note that the argument types are enforced for the per-field custom
> >> + * functions.
> >> + */
> >> +#define JUMBLE_CUSTOM(nodetype, item) \
> >> + _jumble##nodetype##_##item(jstate, expr, expr->item)
>
> In this one, I want to mean that we require a custom per-fiel
On Fri, Mar 21, 2025 at 05:26:20PM +0100, Christoph Berg wrote:
> Just one minor thing, I don't understand what you are trying to say in
> this comment:
>
>> +/*
>> + * Note that the argument types are enforced for the per-field custom
>> + * functions.
>> + */
>> +#define JUMBLE_CUSTOM(nodetype,
Re: Michael Paquier
> I have been thinking about this patch for a couple of days. What
> makes me unhappy in this proposal is that RangeTblEntry is a large and
> complicated Node, and we only want to force a custom computation for
> the "relid" portion of the node, while being able to also take so
On Wed, Mar 19, 2025 at 01:02:54PM +0100, Christoph Berg wrote:
> You are of course right, that one-line comment was just snakeoil :D.
> Now there are proper ones, thanks.
I have been thinking about this patch for a couple of days. What
makes me unhappy in this proposal is that RangeTblEntry is a
Re: Michael Paquier
> Fine by me as well to keep a dependency based on the fact that the
> structure is rather complicated, but I'd rather document that as well
> in parsenodes.h with a slightly fatter comment. What do you think?
You are of course right, that one-line comment was just snakeoil :D
t;
>AppendJumble(jstate, (const unsigned char *)"pg_temp",
> sizeof("pg_temp"));
>AppendJumble(jstate, (const unsigned char *)rel_name,
> strlen(rel_name));
Yes, I know that it's not a big deal, but it could be confusing if
somebody makes an
Re: Michael Paquier
> This is OK on its own, still feels a bit incomplete, as the relid also
> includes an assumption about the namespace. I would suggested to add
> a hardcoded "pg_temp" here, to keep track of this assumption, at
> least.
I had thought about it, but figured that integers and str
ased.
--
Best regards,
Aleksander Alekseev
From 43e7cdccf1aa96e6522a41518bf0437dda23cc4d Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 11 Sep 2024 13:17:33 +0300
Subject: [PATCH v4] Always use long SLRU segment file names
PG17 introduced long SLRU segment file names (commit
Hi,
> Here is an updated patch. The steps to test it manually are as follows.
>
> Compile and install PostgreSQL from the REL_17_STABLE branch:
>
> [...]
>
> As always, your feedback and suggestions are most welcomed.
Rebased.
--
Best regards,
Aleksander Alekseev
v3-0001-Always-use-long-SLRU-s
Hi,
> For the record, Michael and I had a brief discussion about this
> offlist and decided to abandon the idea of adding TAP tests, relying
> only on buildfarm. Also I will check if we have a clear error message
> in case when a user forgot to run pg_upgrade and running new slru.c
> with old file
heritance-expansion, those happen even later, at planning time.
> > My original
> > proposal of getting rid of system-generated fake names isn't
> > necessary, because you very helpfully pointed out that I can look at
> > whether RTE->alias->aliasname exists to fi
Robert Haas writes:
> Oh, I agree, but I don't see why anyone would care whether rel names
> are unique across different queries. When I mentioned global
> uniqueness, I meant unique within a query, like what
> set_rtable_names() does after the fact.
Okay, but then we still ha
On Thu, Jan 2, 2025 at 3:27 PM Tom Lane wrote:
> Global uniqueness across the database (not single queries) would be
> needed to prevent cases where different views use the same generated
> names. The only way I can see to do that without nasty performance
> costs is to use something
Robert Haas writes:
> On Sun, Dec 22, 2024 at 12:45 PM Tom Lane wrote:
>> In particular, in a situation where we're trying to show a plan for
>> a query with inlined views, EXPLAIN would probably have to have code
>> to unique-ify the names anyway --- there's no w
I do take
> > your point that it works and somebody's probably relying on it, but I
> > don't think you'd pick a name that requires quoting if you were trying
> > to make it easy to use that name in the query.
>
> As you say, some of this is lost in the mists
buffer for link name - MAX_PATH
symbols, though this
buffer must have the place for at least 2 MAX_PATH : substitution and
print names
of the link.
How to reproduce:
If build directory has length ~100 chars or longer,
pg_rewind/004_pg_xlog_symlink
test will fail (Windows, MSVS build)
Steps
ng
> to make it easy to use that name in the query.
As you say, some of this is lost in the mists of time; but I think the
idea was specifically that these names should *not* be easy to type,
because we don't want them to conflict with any relation alias that
the user is likely to pick.
On Mon, 16 Dec 2024 at 21:55, Tom Lane wrote:
> Oh, well if you're willing to cheat like that, sure ;-). I was
> speaking of replacing the existing logic with something that looked
> only at the post-analysis tree.
Yeah, alright. That's not really something that I think we can do
without introdu
Jelte Fennema-Nio writes:
> On Mon, 16 Dec 2024 at 21:09, Tom Lane wrote:
>> However, after thinking a little longer I seem to recall that we've
>> previously looked into the idea of deriving the default aliases from
>> the post-parse-analysis tree. We gave up because there were too many
>> case
char *
-FigureColname(Node *node)
+FigureColname(Node *untransformed, Expr *transformed)
{
char *name = NULL;
- (void) FigureColnameInternal(node, &name);
+ /*
+ * XXX: Could add hook here that receives both transform and untransformed
+ * to allow extensions to create arbitrary column
Jelte Fennema-Nio writes:
> 4. For the custom type that I'm implementing the subscripting for, I
> really don't want such a prefix.
Hm. If we made this behavior type-specific then you could have what
you want without having to break any existing expectations at all.
However, after thinking a li
ere it explicitizes
both the implicit cast, and the implicit column alias.
> > So what would you want here? Do you want these columns to be called 2
> > and 3?
>
> No!!
Good, then we agree on that at least.
> > One thing that I didn't see you explicitly say: Do you ag
?
No!!
> One thing that I didn't see you explicitly say: Do you agree that the
> new column names are actually better than the old ones?
No, I'm not at all convinced of that. For these examples
I'd prefer something like "data_a", "data_b", etc.
That approach
cision that the new way is so much better than
> the old that it's okay to break some people's queries.
> I don't say that bar is unreachable, but it seems high.
Totally fair, that's part of the reason I limited this to only string
literals, to effectively only impact JSON
that don't get resolved as text:
regression=# create table t2 (data int[]);
CREATE TABLE
regression=# insert into t2 values(array[1,2,3,4]);
INSERT 0 1
regression=# select data['2'], data[3] from t2;
data | data
--+--
2 |3
(1 row)
> 1. Change the default alias/e
I'm working on implementing subscripts for a custom type, but one
usability issue I'm running into is that the default column names for
subscript expressions are rather bad.
The easiest way to show this is with json. Running the following in psql:
CREATE TABLE tj(data jsonb);
INSE
Hi,
> I guess we are going to need either a `pg_writecontoldata` tool or
> `pg_controldata -w` flag. I wonder which option you find more
> attractive, or maybe you have better ideas?
For the record, Michael and I had a brief discussion about this
offlist and decided to abandon the idea of adding
On 2024-Dec-02, Alvaro Herrera wrote:
> Oh, you're right, this was unintentional and unnoticed. I'll push this
> shortly, to both 17 and master.
Pushed, thanks Christophe and Bertrand.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
It does it in a really, rea
On 2024-Dec-02, Bertrand Drouvot wrote:
> Hi hackers,
>
> da952b415f unintentionally added back the "Lock" suffix into the LWLock wait
> event names:
>
> - "added back" because the "Lock" suffix was removed in 14a9101091
> - "unintent
Hi hackers,
da952b415f unintentionally added back the "Lock" suffix into the LWLock wait
event names:
- "added back" because the "Lock" suffix was removed in 14a9101091
- "unintentionally" because there is nothing in the thread [2] that explicitly
m
Hi Michael,
> The scans may be quite long as well, actually, which could be a
> bottleneck. Did you measure the runtime with a maximized (still
> realistic) pool of files for these SLRUs in the upgrade time? For
> upgrades, data would be the neck.
Good question.
In theory SLRUs are not suppose
On Tue, Nov 12, 2024 at 05:37:02PM +0300, Aleksander Alekseev wrote:
> Also it occured to me that as a 4th option we could just get rid of
> this check. Users however will pay the price every time they execute
> pg_upgrade so I doubt we are going to do this.
We cannot remove the check, or Nathan w
Hi again,
Just a quick follow-up.
> (*) BTW I noticed a mistake in the commented code. The condition
> should be `>=`, not `<`, i.e:
>
> ```
> if(new_cluster.controldata.cat_ver >= SLRU_SEG_FILENAMES_CHANGE_CAT_VER)
> return;
> ```
The concentration of caffeine in my blood is a bit l
Hi Michael,
Thanks for your feedback!
> Your patch is just doing a rename() of the files from short to long
> names. How about adding a new TAP script in pg_upgrade that creates a
> couple of empty files with short files names in each path that needs
> to do the transfer? Then th
and predictable.
Also, I'm not sure how other extension developers operate, but in a
handful of mine, I use the fact that eref always contains a name - the
relational model requires a name for each (even intermediate) table and
column, doesn't it?
Also, do not forget that these names
referring to it from some other part of your query. I do take
your point that it works and somebody's probably relying on it, but I
don't think you'd pick a name that requires quoting if you were trying
to make it easy to use that name in the query. You might possibly also
try to gene
On Thu, Sep 12, 2024 at 12:33:14PM +0300, Aleksander Alekseev wrote:
> It wouldn't hurt re-checking the segment file names in the TAP test
> but this would mean hardcoding catalog names which as I understand you
> want to avoid. With high probability PG wouldn't start if the
&g
Robert Haas writes:
> On Thu, Nov 7, 2024 at 4:07 PM Tom Lane wrote:
>> Is there some strong reason to insist on making that core-dump-risking
>> change, rather than simply assigning the now-one-size-fits-all alias
>> when creating Alias nodes?
> What I'm unhappy about is not being able to tell
BTW, one aspect of this proposal that needs to be discussed is that
it can break existing SQL. An example discussed nearby[1] is
regression=# select * from (values (1,7), (3,4) order by "*VALUES*".column2);
column1 | column2
-+-
3 | 4
1 | 7
(2 rows)
We
On Thu, Nov 7, 2024 at 4:07 PM Tom Lane wrote:
> Is there some strong reason to insist on making that core-dump-risking
> change, rather than simply assigning the now-one-size-fits-all alias
> when creating Alias nodes?
What I'm unhappy about is not being able to tell the difference
between a nam
Robert Haas writes:
> It's quite possible that this patch isn't completely correct and it's
> also possible that I'm missing some deeper problem with this idea that
> just isn't exercised by the regression tests. But overall I find these
> results fairly encouraging -- it just wasn't very hard to
Forgot to attach the patch.
v1-0001-POC-Don-t-make-up-fake-eref-names.-Just-use-NULL.patch
Description: Binary data
nteresting. I guess we could maybe document that a bit better, but
it's not the main thing to focus on.
I tried replacing all of those fake RTE entry names with NULL and
fixing whatever broke in the regression tests. I attach the result. It
seems like this is basically a problem that applies
On 06.11.24 20:06, Robert Haas wrote:
I can make nothing of*TLOCRN* or*TROCRN*, even
after looking at the relevant source code,
These are from the SQL standard text. So they are more guidance to the
implementer than anything else. I think something had to be put there,
because erefs are req
I have two related questions about this. First, why do we do
it at all? Second, why do we assign the names as we do?
Let me start with the second question. After some surveying of the
source code, here's a (possibly-incomplete) list of eref names that we
fabricate: old, new, *SELECT*, ANY_
On Wed, Oct 9, 2024 at 8:54 PM Michael Paquier wrote:
>
> Applied the previous patch after looking at it again.
> --
> Michael
AFAIK this brings my year-long "GUC names" thread to a conclusion.
Thanks, Michael for helping to get these last couple of patches
pushed, and th
1 - 100 of 602 matches
Mail list logo
