Re: Regarding extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Natarajan R <nataraj3098(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Regarding extension
Date: 2019-10-04 05:17:52
Message-ID: 17058.1570166272@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Natarajan R <nataraj3098(at)gmail(dot)com> writes:
> Me: Thanks Tomas, But this is for that particular database only, I want
> to get the *list of database Id's* on which my extension is installed
> during *PG_INIT* itself...

You can't. In the first place, that information simply isn't obtainable,
because a session running within one database doesn't have access to the
catalogs of other databases in the cluster. (You could perhaps imagine
firing up connections to other DBs a la dblink/postgres_fdw, but that will
fail because you won't necessarily have permissions to connect to every
database.) In the second place, it's a pretty terrible design to be
attempting any sort of database access within _PG_init, because that
precludes loading that module outside a transaction; for example you
will not be able to preload it via shared_preload_libraries or allied
features.

We should back up about three steps and ask why you think you need
to do this. Generally speaking, database code shouldn't be concerning
itself with what is happening in other databases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-10-04 05:31:16 Re: [HACKERS] Block level parallel vacuum
Previous Message Amit Kapila 2019-10-04 05:01:50 Re: [HACKERS] Block level parallel vacuum