On Wed, Dec 17, 2025 at 3:29 PM Dilip Kumar <[email protected]> wrote: > > On Wed, Dec 17, 2025 at 3:14 PM shveta malik <[email protected]> wrote: > > > > I don’t think a user intentionally dropping information_schema and > > creating their own schema (with different definitions and tables) is a > > practical scenario. While it isn’t explicitly restricted, I don’t see > > a strong need for it. OTOH, there are scenarios where, after fixing > > issues that affect the definition of information_schema on stable > > branches, users may be asked to reload information_schema to apply the > > updated definitions. One such case can be seen in [1]. > > > > Additionally, while reviewing the code, I noticed places where the > > logic does not rely solely on relid being less than > > FirstNormalObjectId. Instead, it performs name-based comparisons, > > explicitly accounting for the possibility that information_schema may > > have been dropped and reloaded. This further indicates that such > > scenarios are considered practical. See [2]. > > And if such scenarios are possible, it might be worth considering > > keeping the publish behavior consistent, both before and after a > > reload of information_schema. > > > > [1]: > > https://www.postgresql.org/docs/9.1/release-9-1-2.html > > > > [2]: > > pg_upgrade has this: > > static DataTypesUsageChecks data_types_usage_checks[] = > > { > > /* > > * Look for composite types that were made during initdb *or* > > belong to > > * information_schema; that's important in case information_schema > > was > > * dropped and reloaded. > > * > > * The cutoff OID here should match the source cluster's value of > > * FirstNormalObjectId. We hardcode it rather than using that C > > #define > > * because, if that #define is ever changed, our own version's > > value is > > * NOT what to use. Eventually we may need a test on the > > source cluster's > > * version to select the correct value. > > */ > > { > > .status = gettext_noop("Checking for system-defined > > composite types in user tables"), > > .report_filename = "tables_using_composite.txt", > > .base_query = > > "SELECT t.oid FROM pg_catalog.pg_type t " > > "LEFT JOIN pg_catalog.pg_namespace n ON t.typnamespace = > > n.oid " > > " WHERE typtype = 'c' AND (t.oid < 16384 OR nspname = > > 'information_schema')", > > Yeah I agree with your theory. While the system allows users to > manually create an information_schema or place objects within it, we > are establishing that anything inside this schema will be treated as > an internal object. If a user chooses to bypass these conventions and > then finds the objects are not handled like standard user tables, it > constitutes a usage error rather than a system bug.
Yes, I think so as well. IIUC, we wouldn’t be establishing anything new here; this behavior is already established. If we look at the code paths that reference information_schema, it is consistently treated as similar to system schema rather than a user schema. A few examples include XML_VISIBLE_SCHEMAS_EXCLUDE, selectDumpableNamespace, data_types_usage_checks, describeFunctions, describeAggregates, and others. thanks Shveta
