Re: Added schema level support for publication. - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: Added schema level support for publication.
Date
Msg-id CAFPTHDZ_c9RTvrFwkAHUvwqoQWrnS_U_hgyW7Ku0GQNof4J_xQ@mail.gmail.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (vignesh C <vignesh21@gmail.com>)
Responses Re: Added schema level support for publication.
List pgsql-hackers
On Mon, Jun 21, 2021 at 3:16 PM vignesh C <vignesh21@gmail.com> wrote:


> I felt this is ok as we specify the keycount to be 1, so only the
> key[0] will be used. Thoughts?
> ScanKeyInit(&key[0],
> Anum_pg_class_relkind,
> BTEqualStrategyNumber, F_CHAREQ,
> CharGetDatum(RELKIND_PARTITIONED_TABLE));
>
> scan = table_beginscan_catalog(classRel, 1, key);
>

It maybe fine, just doesn't look correct when you look at the function
as a whole.

> > =================================
> >
> > in UpdatePublicationTypeTupleValue():
> >
> > + tup = heap_modify_tuple(tup, RelationGetDescr(rel), values, nulls,
> > + replaces);
> > +
> > + /* Update the catalog. */
> > + CatalogTupleUpdate(rel, &tup->t_self, tup);
> >
> > Not sure if this tup needs to be freed or if the memory context will
> > take care of it.
>
> I felt this is ok, as the cleanup is handled in the caller function
> "AlterPublication", thoughts?
> /* Cleanup. */
> heap_freetuple(tup);
> table_close(rel, RowExclusiveLock);

that should be fine.

regards,
Ajin Cherian
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Different compression methods for FPI
Next
From: David Rowley
Date:
Subject: Re: Use simplehash.h instead of dynahash in SMgr