The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
Prohibit direct update of GC_REFCOUNT(), GC_SET_REFCOUNT(), GC_ADDREF() and GC_DELREF() shoukf be instead.
Added mactros to validate reference-counting (disabled for now).
These macros are going to be used to eliminate race-condintions during reference-counting on data shared between threads.
Executing prepared statements is succesfull only for the first two statements
The reworked patch descends to the bug #69526 which is fixed by
this as well. The broken logic in the current code was, that
SQLDescribeParam was executed in odbc_execute every time. This piece
is now moved into odbc_prepare and the results are carried on in an
additional structure.
Since the ext/odbc headers are not being currently installed and the
corresponding structs like odbc_result are not used outside ext/odbc,
the binary compatibility persists. Executing SQLDescribeParam only once
in odbc_prepare is also an optimization as the filds usually won't
change that fast and thus requestind the descriptions on every
execution is not required.
The SQL Server Native Client 11.0 and maybe other ODBC drivers report
NVARCHAR(MAX) columns as SQL_WVARCHAR with size 0. This causes too small a
buffer to be emalloc'd, likely causing a segfault in the following. As we don't
know the real size of the column data, we treat such colums as
SQL_WLONGVARCHAR.
The related bug #67437 suggests that some drivers report a size of ~4GB. It is
not certain that this is really the case (there might be some integer overflow
involved, and anyway, there has been no feedback), so we do not cater for this
now. However, it would not be hard to treat all sizes above a certain threshold
in a similar way, i.e. as SQL_WLONGVARCHAR.
This is just a hotfix as there are still drivers with no full
ODBC 3.x support. This patch origins from bug #68350 which was
solved by the proper 3.0 migration, another driver (Sage)
turned out to have the real issue.
