Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: [INTERFACES] retrieving varchar size |
Дата | |
Msg-id | 199804240405.AAA25030@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [INTERFACES] retrieving varchar size (Byron Nikolaidis <byronn@insightdist.com>) |
Ответы |
Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
|
Список | pgsql-hackers |
> > > > Bruce Momjian wrote: > > > > The problem with that theory is this. If the frontend application just > > > executes some random query, such as "select * from table", you really do not > > > know anything about what is coming back. You must rely on the little bit of > > > information the protocol gives you. In the case of Postgres, it gives you > > > the fieldname, datatype, and size for each column in the result. > > > Unfortunately, for varchar and char(n), the size reports -1. This is not > > > very helpful for describing the result set. > > > > > > Your above example works fine (in fact we use that already) when you know the > > > table and column name, as in metadata functions such as SQLColumns() in the > > > ODBC driver. > > > > Yep. We could pass back atttypmod as part of the PGresult. I can add > > that to the TODO list. Would that help? > > Yes, that would do it! > > Thank you for listening to our ravings on this issue. Added to TODO: * Add pg_attribute.atttypmod/Resdom->restypmod to PGresult structure This is a good suggestion. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: