On 15 April 2013 21:32, Jaime Casanova <ja...@2ndquadrant.com> wrote: > On Mon, Apr 15, 2013 at 3:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> OTOH, the notion that a UUID generator doesn't touch *any* database >> state seems like it might be worth treating as a general function >> property: it's simple to understand and applies to a lot of other >> volatile functions such as random() and clock_timestamp(). >> > > Something like the NO SQL access indication mandated by sql standard? > > http://www.postgresql.org/message-id/1267473390.7837.9.ca...@vanquo.pezone.net
That would work for UUIDs, random() etc but not for sequences. So I'll treat this as two separate cases: * add special case for sequences * use the NO SQL mechanism, as described, which implies no reads or writes of database state. We could test that, but its somewhat harder and we'd need to test for that on entry to any function, which I don't much like. Default to current timestamp is also a common use case - thanks for mentioning that. Doing it tha way Tatsuo would be able to parse functions more easily as requested in the linked post. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
