Joe Conway wrote:
> 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/
