Recasting types
От | Graham Wilson |
---|---|
Тема | Recasting types |
Дата | |
Msg-id | 20030109105008.88655.qmail@web14403.mail.yahoo.com обсуждение исходный текст |
Ответы |
Re: Recasting types
|
Список | pgsql-interfaces |
I have brought this up on the list before so feel free to tell me to shut up and stop whining. I am actually generally quite happy with postgres but I have a few comments on how to improve libpq... My concern is with the lack of explicit type casting functions in libpq. I understand the reasoning for passing data around in ASCII and recognize that byte ordering and sizing is problematic when moving binary data between machines of different types. Nevertheless, I feel the lack for sound type casting of returned ASCII data returned from postgresql is a serious shortcoming of libpq. As we all know, for non-binary types, the returned pointer from PQexec points to ASCII data that is retireved as a character pointer with PQgetvalue. However, from a user's perspective, if the data is an integer, then there must be some way to cast it as such! I don't care that the backend keeps this data as ASCII, that is semantic. As it stands, PQgetvalue returns a character ointer that the programmer must somehow cast with little knowledge of the type. At present, all that can be determined is the internal oid returned by PQftype. From this oid, one can then do a lookup on a template database to get a character representation of the type (i.e. "int2" or "int4"). Comparing this type with a list of known types then allows one to cast the data appropriately, but it is a large amount of unneccessary work for the application programmer (IMHO). Effectively, what I am asking for is a set of abstracted tools that can parse every postgres datatype into a suitable c type with an open definition that is known to libpq-fe.h. With regard to binary data, I would like to see a set of transparent tools that can perform raw conversion of the returned data stream. Again, why should an application programmer have to concern himself/herself with converting the binary stream simply because the server has different endiness conventions than his local machine? This is not as difficult as one might think... Endiness and most other binary conversions can easily be checked during the compiling of a local libpq and simply passing a 'known' long long integer in the PGConn structure would provide enough information to figure out how to mangle the binary stream. Please reply to the list. Thanks, Graham ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca
В списке pgsql-interfaces по дате отправления: