Thread: PGDOCS - function pg_get_publication_tables is not documented?

Hi hackers,

While reviewing another thread [1] I could not find the function
'pg_get_publication_tables' described anywhere in the PG
documentation.

Should it be mentioned somewhere like the "System Catalog Information
Functions" table [2], or was this one deliberately omitted for some
reason?

Thanks.

------
[1] https://www.postgresql.org/message-id/CAA4eK1KrzTOYsuCzz6fxRed37C6MfHE1t9kyrM5B4m9ToqKWrQ%40mail.gmail.com
[2] https://www.postgresql.org/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE

Kind Regards,
Peter Smith.
Fujitsu Australia

Peter Smith <smithpb2250@gmail.com> writes:
> While reviewing another thread [1] I could not find the function
> 'pg_get_publication_tables' described anywhere in the PG
> documentation.
> Should it be mentioned somewhere like the "System Catalog Information
> Functions" table [2], or was this one deliberately omitted for some
> reason?

It's not documented because it's intended only as infrastructure
for the pg_publication_tables view.  (There are some other functions
in the same category.)

I do see a docs change that I think would be worth making: get
rid of the explicit mention of it in create_subscription.sgml
in favor of using that view.

            regards, tom lane

On Fri, Mar 24, 2023 at 9:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Smith <smithpb2250@gmail.com> writes:
> > While reviewing another thread [1] I could not find the function
> > 'pg_get_publication_tables' described anywhere in the PG
> > documentation.
> > Should it be mentioned somewhere like the "System Catalog Information
> > Functions" table [2], or was this one deliberately omitted for some
> > reason?
>
> It's not documented because it's intended only as infrastructure
> for the pg_publication_tables view.  (There are some other functions
> in the same category.)
>
> I do see a docs change that I think would be worth making: get
> rid of the explicit mention of it in create_subscription.sgml
> in favor of using that view.
>

OK. Thanks very much for the information.

------
Kind Regards,
Peter Smith.
Fujitsu Australia

On Fri, Mar 24, 2023 6:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> I do see a docs change that I think would be worth making: get
> rid of the explicit mention of it in create_subscription.sgml
> in favor of using that view.
> 

I agree and I tried to modify the query to use the view.
Please see the attached patch.

Regards,
Shi Yu

On Sun, Apr 9, 2023 at 7:35 AM Yu Shi (Fujitsu) <shiy.fnst@fujitsu.com> wrote:
>
> On Fri, Mar 24, 2023 6:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > I do see a docs change that I think would be worth making: get
> > rid of the explicit mention of it in create_subscription.sgml
> > in favor of using that view.
> >
>
> I agree and I tried to modify the query to use the view.
> Please see the attached patch.
>

I am wondering whether we need to take the publication name as input
to find tables that can include non-local origins. I think anyway
users need to separately query publication names to give that input.

--
With Regards,
Amit Kapila.

"Yu Shi (Fujitsu)" <shiy.fnst@fujitsu.com> writes:
> On Fri, Mar 24, 2023 6:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I do see a docs change that I think would be worth making: get
>> rid of the explicit mention of it in create_subscription.sgml
>> in favor of using that view.

> I agree and I tried to modify the query to use the view.
> Please see the attached patch.

Ah, now I see why it was written like that: it's kind of annoying
to join to pg_subscription_rel without having access to the relation
OID.  Still, this is more pedagogically correct, so pushed.

            regards, tom lane