Re: Alias collision in `refresh materialized view concurrently` - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Alias collision in `refresh materialized view concurrently`
Date
Msg-id CALj2ACV5Ox8Py-n5EtY9j7_TGGU1p+xBDL2TrtDTpPEafLTr7w@mail.gmail.com
Whole thread Raw
In response to Re: Alias collision in `refresh materialized view concurrently`  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Alias collision in `refresh materialized view concurrently`
List pgsql-hackers
On Wed, Jun 2, 2021 at 6:33 AM Michael Paquier <michael@paquier.xyz> 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 various constraints on unquoted
> > identifiers in the standard (for example, something involving $), but
> > it does seem a shame to remove the ability for users to put absolutely
> > anything except NUL in quoted identifiers.  I do wonder if at least
> > using something like _$mv would be slightly more principled than
> > pg_mv_1234, since nothing says pg_XXX is reserved (except in some very
> > specific places like schema names), and the number on the end seems a
> > bit cargo-cultish.
>
> Yeah, using an underscore at the beginning of the name would have the
> advantage to mark the relation as an internal thing.
>
> +                    "(SELECT %s.tid FROM %s %s "
> +                    "WHERE %s.tid IS NOT NULL "
> +                    "AND %s.%s IS NULL)",
> Anyway, I have another problem with the patch: readability.  It
> becomes really hard for one to guess to which object or alias portions
> of the internal queries refer to, especially with a total of five
> temporary names lying around.  I think that you should drop the
> business with make_temptable_name_n(), and just append those extra
> underscores and uses of MyProcPid directly in the query string.  The
> surroundings of quote_qualified_identifier() require two extra printf
> calls, but that does not sound bad to me compared to the long-term
> maintenance of those queries.

Thanks. PSA v4.

With Regards,
Bharath Rupireddy.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Two patches to speed up pg_rewind.
Next
From: Bharath Rupireddy
Date:
Subject: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options