Dean Rasheed writes:
> On Mon, 2 Oct 2023 at 01:01, Tom Lane wrote:
>> Yeah, that's exposing more of the implementation than we really want.
> Note that this isn't a new issue, specific to unnamed subqueries. The
> same thing happens for unnamed joins:
True, and we've had few complaints about
On Mon, 2 Oct 2023 at 01:01, Tom Lane wrote:
>
> Erwin Brandstetter writes:
> > On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
> >> The only place that exposes the eref's made-up relation name is the
> >> existing query deparsing code in ruleutils.c, which uniquifies it and
> >> generates SQL
Erwin Brandstetter writes:
> On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
>> The only place that exposes the eref's made-up relation name is the
>> existing query deparsing code in ruleutils.c, which uniquifies it and
>> generates SQL spec-compliant output. For example:
> I ran into one
On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
> The only place that exposes the eref's made-up relation name is the
> existing query deparsing code in ruleutils.c, which uniquifies it and
> generates SQL spec-compliant output. For example:
>
I ran into one other place: error messages.
Dean Rasheed writes:
> Attached is an update with the following changes:
> * Docs updated as suggested.
> * transformLockingClause() updated to skip subquery and values rtes
> without aliases.
> * eref->aliasname changed to "unnamed_subquery" for subqueries without
> aliases.
This looks good
On Sat, Jul 9, 2022 at 5:18 AM Dean Rasheed
wrote:
> On Sat, 9 Jul 2022 at 12:24, Zhihong Yu wrote:
> >
> > It seems the code would be more readable if you keep the assignment in
> else block below:
> >
> > + else if (rte->rtekind == RTE_SUBQUERY ||
> > +
On Sat, 9 Jul 2022 at 12:24, Zhihong Yu wrote:
>
> It seems the code would be more readable if you keep the assignment in else
> block below:
>
> + else if (rte->rtekind == RTE_SUBQUERY ||
> +rte->rtekind == RTE_VALUES)
>
On Sat, Jul 9, 2022 at 3:28 AM Dean Rasheed
wrote:
> On Wed, 6 Jul 2022 at 15:09, Dean Rasheed
> wrote:
> >
> > I'll post an update in a little while, but first, I found a bug, which
> > revealed a pre-existing bug in transformLockingClause(). I'll start a
> > new thread for that, since it'd be
On Wed, 6 Jul 2022 at 15:09, Dean Rasheed wrote:
>
> I'll post an update in a little while, but first, I found a bug, which
> revealed a pre-existing bug in transformLockingClause(). I'll start a
> new thread for that, since it'd be good to get that resolved
> independently of this patch.
>
On Tue, 5 Jul 2022 at 19:00, Tom Lane wrote:
>
> Dean Rasheed writes:
> > This was discussed previously in [1], and there seemed to be general
> > consensus in favour of it, but no new patch emerged.
>
> As I said in that thread, I'm not super enthused about this, but I was
> clearly in the
Dean Rasheed writes:
> This was discussed previously in [1], and there seemed to be general
> consensus in favour of it, but no new patch emerged.
As I said in that thread, I'm not super enthused about this, but I was
clearly in the minority so I think it should go forward.
> Attached is a
On Tue, 28 Jun 2022 at 00:32, Julien Rouhaud wrote:
> As to forcing SQL-complaint queries, that ship sailed a long time ago:
> > Postgres allows but does not enforce the use of SQL-compliant queries,
> and
> > many of its important features are extensions anyway, so forcing SQL
> > compliant
Hi,
On Mon, Jun 27, 2022 at 12:03:20PM -0400, Isaac Morland wrote:
> On Mon, 27 Jun 2022 at 11:12, Julien Rouhaud wrote:
>
> > More generally, I'm -0.5 on the feature.
> > I prefer to force using SQL-compliant queries, and also not take bad
> > habits.
> >
>
> As to forcing SQL-complaint
On Mon, 27 Jun 2022 at 19:43, David G. Johnston
wrote:
>
> On Mon, Jun 27, 2022 at 11:25 AM Dean Rasheed
> wrote:
>>
>> On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote:
>> >
>> > It doesn't play that well if you have something called subquery though:
>> >
>> > [example that changes a
On Mon, Jun 27, 2022 at 11:25 AM Dean Rasheed
wrote:
> On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote:
> >
> > It doesn't play that well if you have something called subquery though:
> >
> > [example that changes a user-provided alias]
> >
> > While the output is a valid query, it's not
On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote:
>
> It doesn't play that well if you have something called subquery though:
>
> [example that changes a user-provided alias]
>
> While the output is a valid query, it's not nice that it's replacing a
> user provided alias with another one (or
On Mon, 27 Jun 2022 at 11:12, Julien Rouhaud wrote:
> More generally, I'm -0.5 on the feature.
> I prefer to force using SQL-compliant queries, and also not take bad
> habits.
>
As to forcing SQL-complaint queries, that ship sailed a long time ago:
Postgres allows but does not enforce the use
On Mon, Jun 27, 2022 at 9:49 PM Dean Rasheed wrote:
>
> This was discussed previously in [1], and there seemed to be general
> consensus in favour of it, but no new patch emerged.
>
> Attached is a patch that takes the approach of not generating an alias
> at all, which seems to be neater and
This was discussed previously in [1], and there seemed to be general
consensus in favour of it, but no new patch emerged.
Attached is a patch that takes the approach of not generating an alias
at all, which seems to be neater and simpler, and less code than
trying to generate a unique alias.
It
19 matches
Mail list logo
