Re: tinyint and type problems

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/