Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
