libpq / SQL3
От | Chris Bitmead |
---|---|
Тема | libpq / SQL3 |
Дата | |
Msg-id | 39660A6D.3B60BD15@bitmead.com обсуждение исходный текст |
Ответы |
Re: libpq / SQL3
|
Список | pgsql-hackers |
I'm looking at implementing the SQL99 C interface, which looks more or less reasonable. There are some annoyances however. The API to describe the return result SQLDescribeCol takes a pointer to a SQLSMALLINT to return the type of the returned column. There are a whole lot of #define values in the standards document with specified values for each of the standard types. This is annoying because an Oid is bigger than a SQLSMALLINT, and the postgres oid values are not the same as the standards #define values. Now what it is tempting to do is to change the API to instead take a pointer to a Oid, and redefine the #define values to the standard oid values for postgres. However this would obviously be a change to the API. Or I could define a new API, which kinda defeats the purpose of using a standard API since the standard would become largely useless for postgres users. Any thoughts? I'm tempted to define a new datatype typedef Oid SQLDATATYPE; This is what the standard should have done IMHO. It would be one of those minor incompatibilities that people trying to write portable code could easily fix to be portable between implementations, simply by defining this variable as a SQLDATATYPE instead of SQLSMALLINT. Or I could go for a custom API. I guess it's probably all a bit of a wasted argument since only postgres will have implemented the API. Maybe we can set the standard?
В списке pgsql-hackers по дате отправления: