On Sun, May 4, 2014 at 10:06 PM, Tom Lane-2 [via PostgreSQL] < ml-node+s1045698n5802390...@n5.nabble.com> wrote:
> David G Johnston <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5802390&i=0>> > writes: > > Blagoj Petrushev wrote > >> I know for example that redis has this feature, the EXPIRE / EXPIREAT > >> / TTL commands. > >> http://redis.io/commands/expire > > One thought here is that recent versions of the SQL standard contain some > temporal-data features, which might well be usable for the purposes > envisioned here. I'd much rather see us implementing SQL-spec features > than randomly invented ones, so please take a look into the spec before > going too far with EXPIRE. > > ​Slightly different semantics between data valid over a period - but maintained indefinitely - and data that is intentionally desired to be physically removed from the database after a certain point. And the temporal features require, from my recollection, require a specified "AT point-in-time" clause whereas expiration would generally be invisible from the viewpoint of a SELECT writer - hence why polluting existing queries is so high a risk. Since expires seems easier I'm not sure that, if one were to go here first, we'd want decisions made to support the "expires" capability to bleed into a future temporal implementation. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/EXPIRE-as-a-statement-tp5802378p5802391.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
