Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Stephen Frost (sfr...@snowman.net) wrote: > > > Based on Robert's suggestion and using Thom's verbiage, I've tested this > > > out: > > > > > > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ... > > Can't you keep those words as Sconst or something (DefElems?) until the > execution phase, so that they don't need to be keywords at all? I'm > fairly sure we do that kind of thing elsewhere. Besides, that let you > throw errors such as "keyword 'foobarive' not recognized" instead of a > generic "syntax error" if the user enters a bogus permissivity (?) > keyword.
Seems like we could do that, though I'm not convinced that it really gains us all that much. These are only unreserved keywords, of course, so they don't impact users the way reserved keywords (of any kind) can. While there may be some places where we use a string to represent a set of defined options, I don't believe that's typical- certainly something like DISCARD has a set of explicit values, same for CASCADE vs. RESTRICT, replica_identity, TableLikeOption, etc.. We do have a few 'not recognized' messages in the backend, though they're usually 'option %s not recognized' (there aren't any which use 'keyword') and they're in places where we support a list of options to be specified (which also means they require additional code to check for conflicting/redundant options). We could possibly rearrange the entire CREATE POLICY comamnd to use a list of options instead, along the lines of what we do for views: CREATE POLICY p1 ON t1 WITH (command=select,combine_using=AND) USING ...; but that hardly seems better. Perhaps I'm not understanding what you're getting at though- is there something in the existing grammar, in particular, that you're comparing this to? > Is the permissive/restrictive dichotomy enough to support all > interesting use cases? What I think is the equivalent concept in PAM > uses required/requisite/sufficient/optional as possibilities, which > allows for finer grained control. Even there that's just the historical > interface, and the replacement syntax has more gadgets. Restrictive vs. Permissive very simply maps to the logical AND and OR operators. Those are the only binary logical operators we have and it seems unlikely that we're going to get any more anytime soon. I don't believe the comparison to PAM is really fair, as PAM is trying to support the flexibility we already have by allowing users to specify an expression in the policy itself. Perhaps we may wish to come up with a more complex approach for how to combine policies, but in that case, I'd think we'd do something like: CREATE POLICY p1 ON t1 COMBINING ((policy1 AND policy2) OR policy3); though I've not yet come across a case that requires something more complicated than what we can do already with policies and the restrictive / permissive options (note that the case above can be handled that way, in fact, by making policy1 and policy2 restrictive and policy3 permissive). Perhaps that's because that more complicated logic is generally understood and expected to be part of the policy expression itself instead. Also, as mentioned at the start of this thread, the capability for restrictive policies has existed since 9.5, this change is simply exposing that to users without having to require using an extension. Thanks! Stephen
signature.asc
Description: Digital signature
