Michael Paquier writes:
> On Fri, Aug 06, 2021 at 10:48:40AM -0400, Tom Lane wrote:
>> Given that it took this long to notice the problem at all, maybe
>> this is not a fix to cram in on the weekend before the release wrap.
>> But I don't see why we need to settle for "mostly works" when
>> "alway
On Fri, Aug 06, 2021 at 10:48:40AM -0400, Tom Lane wrote:
> AFAICT that works and generates the identical parse tree to the original
> coding. The only place touched by the patch where it's a bit difficult to
> make the syntax unambiguous this way is
>
> "CREATE TEMP TABLE %s
I wrote:
> I just came across this issue while preparing the release notes.
> ISTM that people have expended a great deal of effort on a fundamentally
> unreliable solution, when a reliable one is easily available.
Concretely, I propose the attached.
regards, tom lane
dif
Michael Paquier writes:
> On Wed, Jun 02, 2021 at 03:44:45PM +0530, Bharath Rupireddy wrote:
>> Thanks.The changes with that approach are very minimal. PSA v5 and let
>> me know if any more changes are needed.
> Simple enough, so applied and back-patched.
I just came across this issue while prep
On Wed, Jun 02, 2021 at 03:44:45PM +0530, Bharath Rupireddy wrote:
> Thanks.The changes with that approach are very minimal. PSA v5 and let
> me know if any more changes are needed.
Simple enough, so applied and back-patched. It took 8 years for
somebody to complain about the current aliases, so
On Wed, Jun 2, 2021 at 1:27 PM Michael Paquier wrote:
>
> On Wed, Jun 02, 2021 at 10:53:22AM +0530, Bharath Rupireddy wrote:
> > Thanks. PSA v4.
>
> Thanks for the new version.
>
> +MyProcPid, tempname, MyProcPid, MyProcPid,
> +tempname, MyProcPid, MyProcPid
On Wed, Jun 02, 2021 at 10:53:22AM +0530, Bharath Rupireddy wrote:
> Thanks. PSA v4.
Thanks for the new version.
+MyProcPid, tempname, MyProcPid, MyProcPid,
+tempname, MyProcPid, MyProcPid, MyProcPid,
+MyProcPid, MyProcPid, MyProcPid);
T
On Wed, Jun 2, 2021 at 6:33 AM Michael Paquier wrote:
>
> On Wed, Jun 02, 2021 at 12:30:55PM +1200, Thomas Munro wrote:
> > I wondered if we could find a way to make identifiers that regular
> > queries are prohibited from using, at least by documentation. You
> > could take advantage of the vari
On Wed, Jun 02, 2021 at 12:30:55PM +1200, Thomas Munro wrote:
> I wondered if we could find a way to make identifiers that regular
> queries are prohibited from using, at least by documentation. You
> could take advantage of the various constraints on unquoted
> identifiers in the standard (for ex
On Wed, Jun 2, 2021 at 2:02 AM Bharath Rupireddy
wrote:
> PSA v3 patch. I added a commit message and made some cosmetic adjustments.
Reminds me of this fun topic in Lisp:
https://en.wikipedia.org/wiki/Hygienic_macro#Strategies_used_in_languages_that_lack_hygienic_macros
I wondered if we could f
On Tue, Jun 1, 2021 at 5:24 PM Bernd Helmle wrote:
>
> Am Dienstag, dem 01.06.2021 um 13:13 +0530 schrieb Bharath Rupireddy:
> > I used MyProcPid which seems more random than MyBackendId (which is
> > just a number like 1,2,3...). Even with this, someone could argue
> > that
> > they can look at t
Am Dienstag, dem 01.06.2021 um 13:13 +0530 schrieb Bharath Rupireddy:
> I used MyProcPid which seems more random than MyBackendId (which is
> just a number like 1,2,3...). Even with this, someone could argue
> that
> they can look at the backend PID, use it in the materialized view
> names just to
On Tue, Jun 1, 2021 at 7:11 AM Michael Paquier wrote:
>
> On Fri, May 21, 2021 at 03:56:31PM +0530, Bharath Rupireddy wrote:
> > On Fri, May 21, 2021 at 6:08 AM Michael Paquier wrote:
> >> I am not sure that I see the point of using a random() number here
> >> while the backend ID, or just the PI
On Fri, May 21, 2021 at 03:56:31PM +0530, Bharath Rupireddy wrote:
> On Fri, May 21, 2021 at 6:08 AM Michael Paquier wrote:
>> I am not sure that I see the point of using a random() number here
>> while the backend ID, or just the PID, would easily provide enough
>> entropy for this internal alias
On Fri, May 21, 2021 at 6:08 AM Michael Paquier wrote:
>
> On Thu, May 20, 2021 at 09:14:45PM +0530, Bharath Rupireddy wrote:
> > On Thu, May 20, 2021 at 7:52 PM Bernd Helmle wrote:
> >> "mv" looks like a very common alias (i use it all over the time when
> >> testing or playing around with mater
On Thu, May 20, 2021 at 09:14:45PM +0530, Bharath Rupireddy wrote:
> On Thu, May 20, 2021 at 7:52 PM Bernd Helmle wrote:
>> "mv" looks like a very common alias (i use it all over the time when
>> testing or playing around with materialized views, so i'm wondering why
>> i didn't see this issue al
On Thu, May 20, 2021 at 7:52 PM Bernd Helmle wrote:
>
> Am Mittwoch, dem 19.05.2021 um 18:06 +0530 schrieb Bharath Rupireddy:
> > > The corresponding Code is in `matview.c` in function
> > > `refresh_by_match_merge`. With adding a prefix like `_pg_internal_`
> > > we
> > > could make collisions pr
Am Mittwoch, dem 19.05.2021 um 18:06 +0530 schrieb Bharath Rupireddy:
> > The corresponding Code is in `matview.c` in function
> > `refresh_by_match_merge`. With adding a prefix like `_pg_internal_`
> > we
> > could make collisions pretty unlikely, without intrusive changes.
> >
> > The appended p
On Wed, May 19, 2021 at 5:33 PM Mathis Rudolf wrote:
>
> Hello,
>
> we had a Customer-Report in which `refresh materialized view
> CONCURRENTLY` failed with: `ERROR: column reference "mv" is ambiguous`
>
> They're using `mv` as an alias for one column and this is causing a
> collision with an inte
Hello,
we had a Customer-Report in which `refresh materialized view
CONCURRENTLY` failed with: `ERROR: column reference "mv" is ambiguous`
They're using `mv` as an alias for one column and this is causing a
collision with an internal alias. They also made it reproducible like this:
```
creat
20 matches
Mail list logo
