Re: truncate trigger for foreign data wrappers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: truncate trigger for foreign data wrappers
Date
Msg-id 20160805204802.ixzmzzcinrn4awix@alap3.anarazel.de
Whole thread Raw
In response to Re: truncate trigger for foreign data wrappers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2016-08-05 16:44:20 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
> >> In particular, it seems to me that rather than implement just this,
> >> we really ought to provide an API that lets FDWs actually implement
> >> TRUNCATE if they feel like it.  Having the trigger and not TRUNCATE
> >> capability itself just screams "half baked", wouldn't you say?
> 
> > Both is fine with me. I do object to the position that we need an answer
> > for all utility commands - that seems like a too high hurdle to pass -
> > but implementing truncate for FDWs directly sounds good.
> 
> To clarify: I was certainly not suggesting that we need to implement
> more than that in the first go.  I was just saying that some sort of
> long-term roadmap about utility commands for FDWs would be a good idea.

Well, my problem with that is that I don't see TRUNCATE as being in the
same camp as most other utility commands; thus I'm not sure there's
really a coherent view for it and the rest. In the end it's just an
optimized DELETE, and we didn't say that other DML needs to provide a
view for utility commands either.

- Andres



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Tom Lane
Date:
Subject: Re: Bogus ANALYZE results for an otherwise-unique column with many nulls