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

On Sat, 25 Apr 1998, Bruce Momjian wrote:

> >
> > Yes,  it rings a bell alright,
> >
> > When you execute a multiple query (denoted by semicolans) like "set geqo to
> > 'off'; show datestyle; select * from table", you get that multiple returns and
> > MUST read until you get the 'I'.  If you don't, your screwed the next time you
> > try and read anything cause all that stuff is still in the pipe.
>
> Good point.  If we don't send the empty query, the queued up results get
> out of sync with the requests.
>
> 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.

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