Re: [HACKERS] Re: [INTERFACES] retrieving varchar size - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Date
Msg-id 199804240405.AAA25030@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [INTERFACES] retrieving varchar size  (Byron Nikolaidis <byronn@insightdist.com>)
Responses Re: [HACKERS] Re: [INTERFACES] retrieving varchar size  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Byron Nikolaidis
Date:
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Next
From: Byron Nikolaidis
Date:
Subject: Re: ODBC + Delphi (GREAT!) + some little thing//