On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson <andr...@proxel.se> wrote: > - How should we modify the aggregate functions when upgrading extensions? > ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My current patch > updates the system catalogs directly, which should be safe in this case, but > is this an acceptable solution?
I'd rather extend see us ALTER AGGREGATE to do this. > - Do you think we should add PARALLEL UNSAFE to the functions which we know > are unsafe to make it obvious that it is intentional? That seems likely unnecessary churn from here. > - I have not added the parallel tags to the functions used by our procedural > languages. Should we do so? I don't think that accomplishes anything. > - I have marked uuid-ossp, chkpass_in() and pgcrypto functions which > generate random data as safe, despite that they depend on state in the > backend. My reasoning is that, especially for the pgcrypto functions, that > nobody should not rely on the PRNG state. For uuid-ossp I am on the fence. random() is marked parallel-restricted because of setseed(). If there's no equivalent for other random number generators then I think they can be construed as safe. > - I have touched a lot of legacy libraries, like tsearch2 and the spi/* > stuff. Is that a good idea? I don't know. It doesn't seem particularly important, but I can't immediately see a reason not to do it either. You could argue it might allow for better test coverage... > - I decided to ignore that isn_weak() exists (and would make all input > functions PARALLEL RESTRICTED) since it is only there is ISN_WEAK_MODE is > defined. Is that ok? That seems fine. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
