Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Re: [INTERFACES] retrieving varchar size |
Дата | |
Msg-id | 353F7A47.3C8D677F@sid.trust.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [INTERFACES] retrieving varchar size (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > > > Byron Nikolaidis wrote: > > > > > > Hello, > > > > > > I was wondering if it would be possible, in the Postgres backend, to > > > send back the defined column size for the varchar data type (and > > > possibly the char() type, i.e., bpchar) on a query? Currently, it just > > > sends back -1 for the size, which makes it difficult in the frontend > > > (i.e., odbc driver) to determine what the size of the column is. > > This is kind of tough to do. What makes it tough? Is this info not available where needed, or is changing the protocol tough. In the latter case, I would suggest an additional SQL command for open cursors, or a pseudo table for open cursor where you could do a simple select statement: DECLARE CURSOR FOO_CURSOR FOR SELECT * FROM MYTABLE; SELECT _FIELD_NAME,_FIELD_TYPE,_FIELD_SIZE FROM FOO_CURSOR_INFO_PSEUTOTABLE; > > While the right solution to this is of course getting the size from > > backend, there exists a workaround now (assuming that the query is not > > too expensive). While ASCII cursors always hide the varchar sizes, > > binary ones return the size in actual data (by zero-padding the > > returned data to max size), so one can determine the actual max > > sizes by opening the query in binary cursor and then examining > > enough records to get one non-null field for each varchar field. > > As of 6.3, this is only true of char() fields. Varchar() is now > variable length. As knowing field size is quite essential for Borland applications some solution should be found for this. Hannu
В списке pgsql-hackers по дате отправления: