Remove driver specific support from ODBC #15727
Open
+16
−597
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NattyNarwhal
commented
Sep 3, 2024
cmb69
reviewed
Sep 6, 2024
NattyNarwhal
force-pushed
the
odbc-driver-purge
branch
from
715ba27 to
de911c2
Compare
|
Rebased this; I also suspect |
|
RFC approved, I'll take another look at this. |
PDO_ODBC doesn't do this, and most of these drivers are not in use with PHP, at least like this. Chances are these expose an ODBC driver you can use with a normal driver manager like unixODBC or iODBC. If not, it can be specified as a custom driver, though it does not include any workarounds. There might be some redundant definitions now as a result. IBM Db2 is kept as a special case due to it also being in PDO_ODBC, though I wonder how good of an idea this is. See phpGH-15630
This would only be used on 68k classic Mac OS. Did PHP ever run there?
All supported driver managers can do extended fetches.
So we don't need the define?
There's no justification behind as to why this should be.
NattyNarwhal
force-pushed
the
odbc-driver-purge
branch
from
de911c2 to
efcfe76
Compare
17 tasks
The default handling for turning into SQL_C_CHAR is fine, and the special case for Adabas is no longer needed.
The driver managers and even Db2 support this. This would also allow simplifying the fetch code to merge fetch_into and fetch_array into a single implementation perhaps.
|
FWIW, I think this should be good to review. I have some ideas on how to clean up the fetch code if we can assume all the driver managers implement them, but that should be done in a separate PR. I'm also not sure of removing the Db2 special casing, as it seems Zend was using it in the past at least. |
DanielEScherzer
approved these changes
Aug 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See GH-15630 for motivation and some concerns. Looks like we can get rid of a bunch of ifdefs!
Additional ones I've had since this:
SQL_TIMESTAMPis gated behind Adabas for some reason (inodbc_bindcols), even though it seems general? May need to look into how it gets converted toSQL_C_CHARper ODBC ref.SQL_C_CHARbinding should be correct based on display size.HAVE_SQLDATASOURCESonly gets set on Windows, need to test or assume on Unix