Re: libpq / SQL3
От | Chris Bitmead |
---|---|
Тема | Re: libpq / SQL3 |
Дата | |
Msg-id | 39667C12.55A3623B@bitmead.com обсуждение исходный текст |
Ответ на | Re: libpq / SQL3 (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
> 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. That occured to me, but it doesn't seem worth cluttering up the back-end to achieve. > 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. For user-defined types, you're out of luck anyway as far as strictly following the standard. I think what you're saying is strictly follow the standard anyway. I guess you're right, it's just annoying when the standard is slightly lame but could be fixed with some ever-so subtle changes. > > 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. What I'm saying is that if the standard allowed for an SQLDATATYPE type, whose exact type is implementation-defined, then implementations could choose without affecting portablility. > > 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.) Yes that is strange. I started off by defining various types as structures thinking that all those SQLSHORTINT's everywhere were either suggestions, or put there because they didn't have an idea of what the implementation might do. Later I realised that maybe they really mean them to be SHORTINTS, and I wonder whether I should change them back or whether the client doesn't need to know. Looks like I'll change them back I guess to be really strict about it. > 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, That would be worth considering, except that part of the idea of me going to the new API is to avoid some of the annoyances of libpq such as the non-streaming nature of it. Maybe when everyone is comfortable with the stability of the new library then libpq can be redone in terms of SQL3? It would be pretty easy I think. > 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.
В списке pgsql-hackers по дате отправления:
Следующее
От: Philip WarnerДата:
Сообщение: Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...