Re: On the warpath again about ill-considered inclusion nests - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: On the warpath again about ill-considered inclusion nests
Date
Msg-id 20141114021817.GO28859@tamriel.snowman.net
Whole thread Raw
In response to Re: On the warpath again about ill-considered inclusion nests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: On the warpath again about ill-considered inclusion nests  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Well, if you *only* move RowSecurityDesc and not RowSecurityPolicy,
> okay, but that seems a bit useless/inconsistent if I'm reading it
> right that RowSecurityDesc contains a List of RowSecurityPolicy structs.

Yes, good point.

> What seems possibly saner is to just remove the header inclusion in rel.h
> and declare the new Relation field similarly to the way we handle
> rd_fdwroutine and some other fields there:
>
>     /* use "struct" here to avoid needing to include rowsecurity.h: */
>     struct RowSecurityDesc *rsdesc;    /* Row-security policy, or NULL */

Makes sense to me.

> And while you are at it, how about renaming "rsdesc" to "rd_rsdesc"?
> The fact that whoever put in trigdesc didn't get the memo about the
> naming convention for Relation fields doesn't excuse you from following
> it.

Ok.  I tend to be bad and mistakenly consider existing code 'gospel'.
Will fix.

> PS: The comments for struct RowSecurityPolicy could stand to be improved.

Understood, will do so.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: On partitioning
Next
From: Steve Singer
Date:
Subject: Re: logical decoding - reading a user catalog table