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

From David Hartwig
Subject Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Date
Msg-id 353F96B3.E75DB188@insightdist.com
Whole thread Raw
In response to Re: [HACKERS] Re: [INTERFACES] retrieving varchar size  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
List pgsql-hackers

Bruce Momjian wrote:

> >
> > 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;
>
> The information you want is in pg_attribute.atttypmod.  It is normally
> -1, but is set for char() and varchar() fields, and includes the 4-byte
> length.  See bin/psql/psql.c for a sample of its use.

I see everyone writing in terms of length.   You do mean precision, don't
you?    For our purposes, this precision should  arrive in the result
header.   (redundancy in each tuple could be over looked)   The goal is to be
able to put realistic bounds on memory allocation before the entire result is
read in.   For this to work, functions must also be able to propagate the
their precision.

Did I spell doom to this idea?

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size