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
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) |