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.
> > I experimented with the attached patch to
On Thu, Jan 2, 2025 at 5:11 PM Tom Lane wrote:
> Okay, but then we still have the problem of how to ensure that in
> a query that has inline'd some views. I think solving the sort of
> I-want-to-reference-this problem you describe would require
> that we unique-ify the aliases in the rewriter, ju
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 have the problem of ho
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 like an OID
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 way we're going to make
>> these n
On Sun, Dec 22, 2024 at 12:45 PM Tom Lane wrote:
> > Hmm, OK, that's useful. But I guess I'm still puzzled about the theory
> > here. A name like *VALUES* doesn't seem like it was created with the
> > idea of referring to it from some other part of your query. I do take
> > your point that it work
[ this thread seems to have stalled out, but we need to resolve it ]
Robert Haas writes:
>>> What I'm unhappy about is not being able to tell the difference
>>> between a name that was invented by or at least meaningful to the user
>>> and one that isn't.
>> You can already tell that, by looking
On 11/8/24 20:33, Robert Haas wrote:
On Thu, Nov 7, 2024 at 4:38 PM Tom Lane wrote:
The trick there is to keep them predictable, because as I mentioned in
my previous response, there may be people depending on knowing what
name will be assigned. We're working with a ton of history here,
and I'
On Thu, Nov 7, 2024 at 4:38 PM Tom Lane wrote:
> > What I'm unhappy about is not being able to tell the difference
> > between a name that was invented by or at least meaningful to the user
> > and one that isn't.
>
> You can already tell that, by looking to see whether
> RTE->alias->aliasname exi
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
On Thu, Nov 7, 2024 at 2:05 AM Peter Eisentraut wrote:
> 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 e
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
16 matches
Mail list logo
