| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Myles Lewis <myles93(at)sbcglobal(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add mssql_compat extension with DATEDIFF function |
| Date: | 2025-11-26 04:18:35 |
| Message-ID: | aSZ_m554kWWt2Qwn@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 25, 2025 at 09:15:37PM +0100, Peter Eisentraut wrote:
> I think this could best live as an external project.
Likely so. Looking at the patch, everything written in it does not
depend directly on something external, with all the function internals
being written based on Postgres APIs. Now, including this
compatibility layer even as a contrib module would have a cost: why
would it be a good idea to bear the cost of such a module in core,
where we would need to maintain compatibility depending on what mssql
decides in its own product? Perhaps this is unlikely, but this
possibility means an extra maintenance burden here.
By the way, when proposing patches, I'd recommend to include
some documentation in them. Proposals in work-in-progress form as OK
as well, of course, if your goal is to take the temperature. I'm on
the same side as Peter here: this proposal would have a better life if
maintained externally.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhijie Hou (Fujitsu) | 2025-11-26 04:25:55 | RE: Assertion failure in SnapBuildInitialSnapshot() |
| Previous Message | Shlok Kyal | 2025-11-26 04:00:15 | Re: How can end users know the cause of LR slot sync delays? |