On Fri, Aug 11, 2023 at 12:48:17PM -0700, David Zhang wrote:
>
> Applied v3 patch to master and verified it with below commands,
Thanks for testing!
> [..]
>
> For below changes,
>
> else if (TailMatches("CREATE", "VIEW", MatchAny, "AS") ||
> - TailMatches("CREATE", "OR", "REPLACE", "VIEW", MatchAny,
> "AS"))
> + TailMatches("CREATE", "VIEW", MatchAny, "WITH", "(*)", "AS")
> ||
> + TailMatches("CREATE", "OR", "REPLACE", "VIEW", MatchAny, "AS")
> ||
> + TailMatches("CREATE", "OR", "REPLACE", "VIEW", MatchAny,
> "WITH", "(*)", "AS"))
>
> it would be great to switch the order of the 3rd and the 4th line to make a
> better match for "CREATE" and "CREATE OR REPLACE" .
I don't see how it would effect matching in any way - or am I
overlooking something here?
postgres=# CREATE VIEW v <tab>
AS WITH (
postgres=# CREATE VIEW v AS <tab>
.. autocompletes with "SELECT"
postgres=# CREATE VIEW v WITH ( security_invoker = true ) <tab>
.. autocompletes with "AS" and so on
And the same for CREATE OR REPLACE VIEW.
Can you provide an example case that would benefit from that?
>
> Since it supports <tab> in the middle for below case,
> postgres=# alter view v set ( security_<tab>
> security_barrier security_invoker
>
> and during view reset it can also provide all the options list,
> postgres=# alter view v reset (
> CHECK_OPTION SECURITY_BARRIER SECURITY_INVOKER
>
> but not sure if it is a good idea or possible to autocomplete the reset
> options after seeing one of the options showing up with "," for example,
> postgres=# alter view v reset ( CHECK_OPTION, <tab>
> SECURITY_BARRIER SECURITY_INVOKER
I'd rather not add this and leave it as-is. It doesn't add any real
value - how often does this case really come up, especially with ALTER
VIEW only having three options?
Thanks,
Christoph