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 199804261424.KAA00326@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [INTERFACES] retrieving varchar size  (Peter T Mount <psqlhack@retep.org.uk>)
Responses Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
List pgsql-hackers
> > One solution is to handle it the way psql does.  It keeps track of the
> > quotes, backslashes, and semicolons in the input string, and sends just
> > one query each time to the backend, and prints the results.
> >
> > Now, with libpq, I think the proper solution would be to scan the input
> > string, and count the number of queries being send, send the whole
> > strings (with the multiple queries) and retrieve that many answers from
> > the backend, discarding all but the last result.  If you do that, I can
> > remove the stuff from psql.c.
>
> I think for libpq, that would be a good idea, but it would mean that there
> is a difference in behaviour between the interfaces.
>
> The JDBC spec allows for multiple ResultSet's to be returned from a query,
> and our driver handles this already.

Oh.  That prevents us from changing the backend to ignore returning more
than one result for multiple queries in a PQexec.  Perhaps we need a new
return query protocol character like 'J' to denote query returns that
are not the LAST return, so libpq can throw them away, and jdbc and
process them as normal, but also figure out when it gets the last one.


>
> Now is this the client libpq, or the backend libpq you are thinking of
> changing? If it's the backend one, then this will break JDBC with multiple
> result sets.
>
> > > Question though, I didnt think my request would have caused a major protocol
> > > change.  I though that the '-1' would simply be replaced by the correct size?
> >
> > Well, the -1 is in attlen, which is the type length.  text, char,
> > varchar are all varlena(variable length)/-1.  atttypmod is the length
> > specified at attribute creation time.  It is similar, but not the same
> > as the length, and trying to put the typmod in the length field really
> > messes up the clarity of what is going on.  We added atttypmod to
> > clarify the code in the backend, and it should be sent to the front end.
> > Soon, maybe will have atttypmod specifiying the precision of DECIMAL, or
> > currency of MONEY.
>
> That would be useful.
>
> > As far as adding atttypmod to libpq, I say do it.  If you look in the
> > backend's BeginCommand(), under the Remote case label, you will see it
> > sending the atttypid to the front end, using the TupleDesc that was
> > passed to it.  Just after sending the atttyplen, I can send the
> > atttypmod value, which is an int16.  I can do all the backend changes.
> > There are a few places where this would have to be changed in the
> > backend.
> >
> > Other front-end libraries reading this protocol will have to change to
> > to accept this field.
>
> As soon as you do it, I'll convert JDBC.
>
> --
> Peter T Mount  peter@retep.org.uk or petermount@earthling.net
> Main Homepage: http://www.demon.co.uk/finder (moving soon to www.retep.org.uk)
> ************ Someday I may rebuild this signature completely ;-) ************
> Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
>
>


--
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: Bruce Momjian
Date:
Subject: Re: [HACKERS] User names cannot contain `-'
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] pq_sendoob/pq_recvoob