| From: | Jose Luis Tallon <jltallon(at)adv-solutions(dot)net> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: [PATCH] Implement uuid_version() |
| Date: | 2019-07-02 08:35:28 |
| Message-ID: | a0ecd831-4023-f763-c1e2-f5c705f2b320@adv-solutions.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/7/19 9:26, Peter Eisentraut wrote:
> On 2019-06-30 14:50, Fabien COELHO wrote:
>> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
>> it is available in core?
> That would probably require an extension version update dance in
> pgcrypto. I'm not sure if it's worth that. Thoughts?
What I have devised for my upcoming patch series is to use a
compatibility "shim" that calls the corresponding core code when the
expected usage does not match the new names/signatures...
This way we wouldn't even need to version bump pgcrypto (full backwards
compatibility -> no bump needed). Another matter is whether this should
raise some "deprecation warning" or the like; I don't think we have any
such mechanisms available yet.
FWIW, I'm implementing an "alias" functionality for extensions, too, in
order to achieve transparent (for the user) extension renames.
HTH
Thanks,
/ J.L.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-07-02 08:38:29 | Re: mcvstats serialization code is still shy of a load |
| Previous Message | Julien Rouhaud | 2019-07-02 08:30:57 | Re: Add parallelism and glibc dependent only options to reindexdb |