Re: On the warpath again about ill-considered inclusion nests

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 23:01:42
Message-ID: 20141114230142.GN28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All,

* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> * 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.

And, done.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-15 00:37:33 Re: initdb -S and tablespaces
Previous Message Robert Haas 2014-11-14 22:14:05 Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS