Re: libpq / SQL3
От | Peter Eisentraut |
---|---|
Тема | Re: libpq / SQL3 |
Дата | |
Msg-id | Pine.LNX.4.21.0007072358220.587-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | libpq / SQL3 (Chris Bitmead <chris@bitmead.com>) |
Ответы |
Re: libpq / SQL3
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
Chris Bitmead writes: > 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. Then it seems we need to add a column to pg_type to keep track the "sqltypeid" as an int2. It would be annoying but doable. The alternative for the moment would be to hard-code the translation at the client side, i.e., have SQLDescribeCol translate the oid it received to some standard number, but that would have obvious problems with user-defined types. > I'm tempted to define a new datatype > typedef Oid SQLDATATYPE; > This is what the standard should have done IMHO. The standard doesn't require that system catalogs are implemented as user-space tables, but equating types to oids would have effectively imposed that requirement. > 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? I wonder. I doubt that they invented this API out of the blue. (Although quite honestly it sometimes looks like it. Note how they religiously avoid pointers everywhere.) It looks like a great goal to achieve though. Having a standard as reference is always good. ("It is so because SQL says so." "Your API might be nice, but ours is standard.") Btw., I've been considering implementing this as a rather thin layer on top of libpq, the idea being that those who want to write portable applications can use SQL/CLI, and those who want to use Postgres-specific features use libpq. I guess you'd rather completely replace libpq? I'd be afraid of effectively abandoning libpq, with everything that's build upon it. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: