From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: On the warpath again about ill-considered inclusion nests |
Date: | 2014-11-14 02:18:17 |
Message-ID: | 20141114021817.GO28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Singer | 2014-11-14 03:23:02 | Re: logical decoding - reading a user catalog table |
Previous Message | Stephen Frost | 2014-11-14 02:12:01 | Re: On partitioning |