Shachar Shemesh wrote:
I'll stress again - I don't mind doing all the work associated with any once of the above choices. All I'm asking is that we agree on which one will be best for this project. As far as I'm concerned, Choice 2 involves the least amount of work, but I think Choice 1 will serve everyone better.
Sorry for jumping into this thread so late, but if you don't really need arithmetic operators, index support, and casts to all other numeric types, why not use "char"?
Joe
On a totally unrelated issue - how are the quotes around "char" enforced? I have not seen anything special about it's definition.
Hi Joe,
Thanks for the offer. I actually tried to use "char" before embarking on the quest, but it didn't work out. While my specific client (and I realize that others do need it) don't need many of the above, they do need some of it. As such, the lack of ability to type "insert into foo (char_col) values (5)" meant I couldn't use it.
In any case, I now have (already commited to the OLE DB sources) a solution to this problem. The provider has a list of special types it supports. When first establishing a connection to the database, I query the pg_type table for all of those types, and cache their OIDs. When I need to perform parsing, I look for all the OIDs I know in advance using a "switch", and in the default clause, look for all the OIDs of the non preknown types. It's a reasonable solution, I think.
I would still love it if the definitions for PG_GETARG_UINT8, PG_RETURN_UINT8 and DatumGetInt8 made it into the main tree, as I don't think there is any real reason to define them in my so. That aside, however, my specific problem is solved. I also renamed the type "utinyint", to leave room for a signed 1 byte value if we decide to go that route. (http://gborg.postgresql.org/project/oledb/cvs/co.php/oledb/PgSess.cpp?r=1.1).
As far as I'm concerned, the discussion just turned academic. I'll still love to add the missing feature to get this type in, as I do think it's generally useful. My implementation, however, currently works over a vanilla postgres without a problem.
Shachar
-- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
