isolate pg_net to net schema

[AndrewJackson2020]

Currently pg_net hardcodes everything to a net schema. This schema is created in the sql scripts and is owned by the extension. Even though it has its own dedicated schema you still need to install pg_net in another schema. This ends up with no objects in that schema but it "exists" in that schema for recordkeeping purposes. This commit changes this so that pg_net is declared with the net extension in the control file.

All this being said, I think the ideal behavior is to make pg_net a relocatable extension. There are some difficulties here in that the C source code assumes the net schemas installation. That said I feel like it is still possible. Happy to accept any feedback here.

[AndrewJackson2020]

Looking into this a bit more, postgis is an example of an extension that uses tables, like pg_net. Unlike pg_net, instead of hardcoding the schema name it dynamically looks up the location of the extension with the below function. Given that, maybe the route we should go here is turning this into a relocatable exension.

/*
 * get_extension_schema - given an extension OID, fetch its extnamespace
 *
 * Returns InvalidOid if no such extension.
 */
static Oid
postgis_get_extension_schema(Oid ext_oid)
{
    Oid         result;
    SysScanDesc scandesc;
    HeapTuple   tuple;
    ScanKeyData entry[1];

    Relation rel = table_open(ExtensionRelationId, AccessShareLock);
    ScanKeyInit(&entry[0],
    	Anum_pg_extension_oid,
        BTEqualStrategyNumber, F_OIDEQ,
        ObjectIdGetDatum(ext_oid));

    scandesc = systable_beginscan(rel, ExtensionOidIndexId, true,
                                  NULL, 1, entry);

    tuple = systable_getnext(scandesc);

    /* We assume that there can be at most one matching tuple */
    if (HeapTupleIsValid(tuple))
        result = ((Form_pg_extension) GETSTRUCT(tuple))->extnamespace;
    else
        result = InvalidOid;

    systable_endscan(scandesc);

    table_close(rel, AccessShareLock);

    return result;
}

[AndrewJackson2020]

Another idea: pg_cron has a similar pattern as pg_net: creates a cron schema where everything is installed, non-relocatable, etc. They hardcode the installation to pg_catalog though. Maybe we should consider this as an alternative to having pg_cron be non-relocatable but allowing it to be installed anywhere?

https://github.com/citusdata/pg_cron/blob/5cedfa472ccc83567aa23ec645925ed8489a7797/pg_cron.control

[steve-chavez]

They hardcode the installation to pg_catalog though

Could you elaborate on the pros/cons of that? 👀