Thread: simple make check failures

This is my first post to the dev list, so please be gentle. ;)

When using the current head of pgsql, I find four errors when running "make check". They are all of the same nature,
basicallythat the expected.out file has "syntax error", where as psql is saying "parse error".  

I have included the cvs diff of the changes I made. Please feel free to let me know where I have gone wrong, or to tell
me"thanks!" in the case I just happen to be on the right track. ;) 

Jonathan Scott

--
Jonathan Scott, Programmer, Vanten K.K.
jwscott@vanten.com    Tel: 03-5919-0266
http://www.vanten.com    Fax: 03-5919-0267

Jonathan Scott <jwscott@vanten.com> writes:
> When using the current head of pgsql, I find four errors when running "make check". They are all of the same nature,
basicallythat the expected.out file has "syntax error", where as psql is saying "parse error". 
 

What bison version are you using?  That was a bison change a few revs
back.

I'm actually surprised that CVS tip builds at all with a bison that
predates that change.  We are stressing bison because the grammar
is so large.  You really need bison 1.875 or later.  (I think configure
will warn about it if your bison is older, but the warning is easy to
miss in the voluminous configure chatter :-()
        regards, tom lane

Thanks for writing, Tom.

I checked my system, and bison is reporting itself as 1.875. I am using SuSE 9.0, and I did have to upgrade to get that
configurationmessage to go away, AND to make it compile. 
 

Could you recommend a way I could get bison to reproduce that message? Perhaps I should recompile bison from source, so
itdoes not do any kind of backward compatibility stuff? (if you are in fact suggesting that is what the old bison
reported)

Jonathan Scott


On Thu, 26 Feb 2004 00:17:14 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Jonathan Scott <jwscott@vanten.com> writes:
> > When using the current head of pgsql, I find four errors when running "make check". They are all of the same
nature,basically that the expected.out file has "syntax error", where as psql is saying "parse error". 
 
> 
> What bison version are you using?  That was a bison change a few revs
> back.
> 
> I'm actually surprised that CVS tip builds at all with a bison that
> predates that change.  We are stressing bison because the grammar
> is so large.  You really need bison 1.875 or later.  (I think configure
> will warn about it if your bison is older, but the warning is easy to
> miss in the voluminous configure chatter :-()
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 


-- 
Jonathan Scott, Programmer, Vanten K.K.
jwscott@vanten.com    Tel: 03-5919-0266
http://www.vanten.com    Fax: 03-5919-0267

Jonathan Scott <jwscott@vanten.com> writes:
> I checked my system, and bison is reporting itself as 1.875. I am using SuSE 9.0, and I did have to upgrade to get
thatconfiguration message to go away, AND to make it compile. 
 

> Could you recommend a way I could get bison to reproduce that message?

If you did just upgrade bison, I'd suggest "make maintainer-clean" and
then rebuild.  I do not think the Postgres makefiles are able to detect
that you installed a new bison, so they won't automatically re-run bison
to build new output files.  We normally ship the bison output files as
part of distribution tarballs, which is why "make clean" or even "make
distclean" doesn't flush 'em.
        regards, tom lane

Tom Lane wrote:
> Jonathan Scott <jwscott@vanten.com> writes:
> > I checked my system, and bison is reporting itself as 1.875. I am using SuSE 9.0, and I did have to upgrade to get
thatconfiguration message to go away, AND to make it compile. 
 
> 
> > Could you recommend a way I could get bison to reproduce that message?
> 
> If you did just upgrade bison, I'd suggest "make maintainer-clean" and
> then rebuild.  I do not think the Postgres makefiles are able to detect
> that you installed a new bison, so they won't automatically re-run bison
> to build new output files.  We normally ship the bison output files as
> part of distribution tarballs, which is why "make clean" or even "make
> distclean" doesn't flush 'em.

I have updated the text warning about too-old bison to be clearer when
it is a problem:

! *** If you are going to modify the lexer files or build from CVS, the installed
! *** version of Bison is too old.  Bison version 1.875 or later is required.])

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Bruce Momjian wrote:
> ! *** If you are going to modify the lexer files or build from CVS,
> the installed ! *** version of Bison is too old.  Bison version 1.875
> or later is required.])

Bison has nothing to do with the lexer files.

Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > ! *** If you are going to modify the lexer files or build from CVS,
> > the installed ! *** version of Bison is too old.  Bison version 1.875
> > or later is required.])
> 
> Bison has nothing to do with the lexer files.

Oops, sorry, new text:

*** If you are going to modify the grammar files or build from CVS, the installed
*** version of Bison is too old.  Bison version 1.875 or later is required.])


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

   While adapting an application to make use of the new protocol, I've
faced one problem. I cannot execute a prepared query and fetch the result in
several time. The multiple fetch is accessible with cursor in SQL but I
haven't found any way to execute a prepared query in a cursor.
   The documentation clearly state that the protocol support this beahvior,
so I've modified libpq to handle the case by adding to functions :


PQexecPreparedPortal(conn,stmtName,portalName,nParams,paramValues,paramlengt
h,paramFormats,resultFormat,maxrows);
   and
   PQfetchPortal(conn,portalName,maxrows)

   PQexecPreparedPortal is a PQexecPrepared clone but you can specify the
portal in which the result should be put (which might be the unnamed one)
and the maximum number of rows to retreive after the execution.
   PQfetchPortal fetch the next rows.
   This works nicely. I would like to see this included in the standard
libpq, and will submit a patch if this might be usefull, but as it extend
the libpq API there might be more general plan to support the functionality.
   Any comments ?

   cyril

"Cyril VELTER" <cyril.velter@metadys.com> writes:
> so I've modified libpq to handle the case by adding to functions :

> PQexecPreparedPortal(conn,stmtName,portalName,nParams,paramValues,paramlengt
> h,paramFormats,resultFormat,maxrows);

>     and

>     PQfetchPortal(conn,portalName,maxrows)

>     PQexecPreparedPortal is a PQexecPrepared clone but you can specify the
> portal in which the result should be put (which might be the unnamed one)
> and the maximum number of rows to retreive after the execution.

>     PQfetchPortal fetch the next rows.

>     This works nicely.

This looks fairly messy to me.  Seems like the exposed API ought to be
three functions: set up a portal, fetch (up to) N rows from a portal,
close down a portal.  Your proposal confuses the first two and fails to
provide the last.

More generally it might be a good idea to provide lower-level access to
other parts of the extended-query protocol, such as Describe and Sync.
I did not do anything about that in 7.4 for lack of time, but it's still
something that ought to be thought about.
        regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> "Cyril VELTER" <cyril.velter@metadys.com> writes:
> > so I've modified libpq to handle the case by adding to functions :
>
> >
PQexecPreparedPortal(conn,stmtName,portalName,nParams,paramValues,paramlengt
> > h,paramFormats,resultFormat,maxrows);
>
> >     and
>
> >     PQfetchPortal(conn,portalName,maxrows)
>
> >     PQexecPreparedPortal is a PQexecPrepared clone but you can specify
the
> > portal in which the result should be put (which might be the unnamed
one)
> > and the maximum number of rows to retreive after the execution.
>
> >     PQfetchPortal fetch the next rows.
>
> >     This works nicely.
>
> This looks fairly messy to me.  Seems like the exposed API ought to be
> three functions: set up a portal, fetch (up to) N rows from a portal,
> close down a portal.  Your proposal confuses the first two and fails to
> provide the last.
   What do you think of :


PQportalSetup(conn,stmtName,portalName,nParams,paramValues,paramlength,param
Formats,resultFormat);
   Setup a portal (might be the unnamed one) base on a prepared statement.
return an empty resultset.
   PQportalFetch(conn,portalName,maxrows);
   Fetch rows from the portal. Return a resultset (empty when finished)
   PQportalClose(conn,portalName);
   Close the portal, return an empty resultset.


>
> More generally it might be a good idea to provide lower-level access to
> other parts of the extended-query protocol, such as Describe and Sync.
> I did not do anything about that in 7.4 for lack of time, but it's still
> something that ought to be thought about.
   Would be nice. One thing that is missing today is the ability to specify
differents format (text/binary) for each columns. Binary bindings are very
nice (performance wise) for bytea and simple datatypes (int/float), but are
not very easy to deal with for complex ones (numeric come to mind). Speaking
of the numeric datatype, does the binary representation can be considered
stable or is it something that will change from version to version ?
   Do you think that adding the previous three intermediate-level calls
might be usefull ?

   Cyril