eh.. yes to be honest what I create is more similar to an extension rather than a package, I don't believe to be able to create extensions in cloud sql (the actual target db).
However , is there a way to share this preliminar "extension" with the community?
I'm interested to discuss about solution used
For example: the software creates a custom type to manage bitemporality and audit_record inline for each table; but another approach is to use a primitive table inherited by all tables.
I'm quite sure the composite type has one or two fields I can remove.
etc :-D
Hello Adrian,
I've created a schema to handle some specific features.
In the schema there are a couple of tables used by many functions (more than 20).
In other words, I've created a schema as a package (as suggested in many points).
I wish, in a function of this schema, to be able to call each other functions of this schema without adding the schema name in the call instruction.
PostgreSQL isn't really designed for that - especially if you aren't formally creating an extension but simply putting stuff into a schema.
The script code you use to install your makeshift package should handle dynamic schema naming. It's a pain, do you really need to allow the name of the schema to be unknown at installation time?
You should read up on how extensions are implemented - you are basically writing your own CREATE EXTENSION implementation.
In any case, there really aren't any smarts here: explicitly schema qualify your function calls and forget that search_path even exists. Unless you are writing custom operators, and even then, consider search_path to be evil.
David J.
-- Domenico L.
per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]