Re: TRUNCATE on foreign table - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: TRUNCATE on foreign table
Date
Msg-id bf469e1b-d500-9f0d-36fc-e9515594f3bf@oss.nttdata.com
Whole thread Raw
In response to Re: TRUNCATE on foreign table  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers

On 2021/04/13 10:21, Bharath Rupireddy wrote:
> I agree to convert to bits and pass it as int value which is
> extensible i.e. we can pass more extra parameters across if required.

Looks good to me.


> Also I'm not in favour of removing relids_extra altogether, we might
> need this to send some info in future.
> 
> Both 0001 and 0002(along with the new phrasings) look good to me.

Thanks for updating the patches!

One question is; "CONTEXT" of "TRUNCATE_REL_CONTEXT_ONLY" is required?
If not, I'm tempted to shorten the name to "TRUNCATE_REL_ONLY" or something.

+     <structname>Relation</structname> data structures for each
+     foreign tables to be truncated.

"foreign tables" should be "foreign table" because it follows "each"?

+    <para>
+     <literal>behavior</literal> is either
+     <literal>DROP_RESTRICT</literal> or <literal>DROP_CASCADE</literal>.
+     <literal>DROP_CASCADE</literal> indicates that the
+     <literal>CASCADE</literal> option was specified in the original
       <command>TRUNCATE</command> command.

Why did you remove the description for DROP_RESTRICT?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Next
From: Peter Smith
Date:
Subject: PG Docs - logical decoding output plugins - fix typo