Re: truncate trigger for foreign data wrappers

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Murat Tuncer <mtuncer(at)citusdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: truncate trigger for foreign data wrappers
Date: 2016-08-05 20:48:02
Message-ID: 20160805204802.ixzmzzcinrn4awix@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-08-05 16:44:20 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-08-05 20:48:34 Re: Bogus ANALYZE results for an otherwise-unique column with many nulls
Previous Message Peter Geoghegan 2016-08-05 20:46:01 Re: Parallel tuplesort (for parallel B-Tree index creation)