"Brightwell, Adam" <adam.brightw...@crunchydatasolutions.com> writes:
>> You could do:
>>
>> ALTER TABLE table_name ADD POLICY policy_name (quals);
>> ALTER TABLE table_name POLICY FOR role_name IS policy_name;
>> ALTER TABLE table_name DROP POLICY policy_name;
> I am attempting to modify the grammar to support the above syntax.
> Unfortunately, I am encountering quite a number (280) shift/reduce
> errors/conflicts in bison. I have reviewed the bison documentation as well
> as the wiki page on resolving such conflicts. However, I am not entirely
> certain on the direction I should take in order to resolve these conflicts.
> I attempted to create a more redundant production like the wiki described,
> but unfortunately that was not successful. I have attached both the patch
> and bison report. Any help, recommendations or suggestions would be
> greatly appreciated.
20MB messages to the list aren't that friendly. Please don't do that
again, unless asked to.
FWIW, the above syntax is a nonstarter, at least unless we're willing to
make POLICY a reserved word (hint: we're not). The reason is that the
ADD/DROP COLUMN forms consider COLUMN to be optional, meaning that the
column name could directly follow ADD; and the column type name, which
could also be just a plain identifier, would directly follow that. So
there's no way to resolve the ambiguity with one token of lookahead.
This actually isn't just bison being stupid: in fact, you simply
cannot tell whether
ALTER TABLE tab ADD POLICY varchar(42);
is an attempt to add a column named "policy" of type varchar(42), or an
attempt to add a policy named "varchar" with quals "42".
Pick a different syntax.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
