Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Ick! So the dummy_seclabel test more or less only works by accident if I
> > see that correctly. The .so is only loaded because the CREATE EXTENSION
> > in the test triggers a CREATE FUNCTION dummy_seclabel_dummy() ... LANG
> > C.
I set it up that way on purpose, because there doesn't seem to be any
other reasonable way. (It wasn't like that in the original contrib
module).
> But on reflection, doesn't this mean that the entire implementation of
> SECURITY LABEL is broken?
Heck, see the *very first* hunk of this patch:
https://www.postgresql.org/message-id/CACACo5R4VwGddt00qtPmhUhtd%3Dokwu2ECM-j20B6%2BcmgtZF6mQ%40mail.gmail.com
This was found to be necessary during deparsing of SECURITY LABEL
command, and only of that command -- all other DDL is able to pass back
the OID of the corresponding object, so that the deparsing code can look
up the object in catalogs. But for security label providers there is no
catalog, and there is no way to obtain the identify of the label
provider that I can see. Thus the ugly hack in the patch: the parse
node has to be altered during execution to make sure the provider is
correctly set up for deparse to be able to obtain it.
That to me seemed pretty broken, but I found no better way.
I don't think this is dummy_seclabel's fault.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services