On 5/28/14, 2:43 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> What they want is that you use
>> %name-prefix "base_yy"
>> instead of
>> %name-prefix="base_yy"
>> That makes the warning go away.
>
> Oh really!?
>
>> The %something=something syntax is not documented anywhere, so it lo
Peter Eisentraut writes:
> What they want is that you use
> %name-prefix "base_yy"
> instead of
> %name-prefix="base_yy"
> That makes the warning go away.
Oh really!?
> The %something=something syntax is not documented anywhere, so it looks
> like it worked more or less by accident. We
On 5/21/14, 12:29 PM, Tom Lane wrote:
> Vik Fearing writes:
>> I'm getting some more of these, including some I thought you had fixed.
>> Bison 3.0.2 on current head.
>
> I didn't do anything to suppress those warnings:
>
>> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
Vik Fearing writes:
> On 05/21/2014 12:29 PM, Tom Lane wrote:
>> I didn't do anything to suppress those warnings:
>>> gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ
>>> [-Wdeprecated]
>>> %name-prefix="base_yy"
>>> ^
>> because it's hard to see how that's anythi
On 05/21/2014 12:29 PM, Tom Lane wrote:
> Vik Fearing writes:
>> I'm getting some more of these, including some I thought you had fixed.
>> Bison 3.0.2 on current head.
> I didn't do anything to suppress those warnings:
>
>> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
>> [-W
Vik Fearing writes:
> I'm getting some more of these, including some I thought you had fixed.
> Bison 3.0.2 on current head.
I didn't do anything to suppress those warnings:
> gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ
> [-Wdeprecated]
> %name-prefix="base_yy"
> ^^^
I'm getting some more of these, including some I thought you had fixed.
Bison 3.0.2 on current head.
<>
Writing postgres.bki
Writing schemapg.h
Writing postgres.description
Writing postgres.shdescription
gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
[-Wdeprecated]
%name-pre
Hello Heikki,
Thanks for sharing.
Reagrds
On Tuesday, January 28, 2014 3:48 PM, Heikki Linnakangas
wrote:
On 01/28/2014 04:28 PM, salah jubeh wrote:
>> Yes. Bison and flex are not required when building from a source
>> tarball, because the tarball includes the generated files. If you're
On 01/28/2014 04:28 PM, salah jubeh wrote:
Yes. Bison and flex are not required when building from a source
tarball, because the tarball includes the generated files. If you're
building from a git checkout, however, then you need bison and flex. You
will get an error at make, and IIRC a warning a
>Yes. Bison and flex are not required when building from a source
>tarball, because the tarball includes the generated files. If you're
>building from a git checkout, however, then you need bison and flex. You
>will get an error at make, and IIRC a warning at ./configure
Thanks for the quick re
On 01/28/2014 04:14 PM, salah jubeh wrote:
Today, I have noticed that ./configure does not return an error when bison and
flex are missing. Is this intended ?
Yes. Bison and flex are not required when building from a source
tarball, because the tarball includes the generated files. If you're
Hello,
Today, I have noticed that ./configure does not return an error when bison and
flex are missing. Is this intended ?
OS: Ubuntu 13.04
Regards
Andres Freund writes:
> On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
>>> It looks like our choices are (1) teach configure to enable
>>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9.
>>>
>>> I am in favor o
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> The bottom line was:
> >>> It looks like our choices are (1) teach configure to enable
> >>> -fno-aggressive-loop-optimizat
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch wrote:
> Agreed. Let's stick an "Updates OS packages daily, regularly acquiring
> bleeding-edge upstream releases" note on the buildfarm status page
FWIW, I added "[updated daily]" to the OS version field.
I haven't changed other configuration yet, wi
On Mon, Jul 29, 2013 at 11:05:52AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages
> >> daily.
> >> I assumed that's a good thing -- the purpose of build farm is to test
>
* Andrew Dunstan wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm
client where it wouldn't do a git pull, but would report changes if the
build result was different from the previous result. You'd run this
immediately after pulling new changes into your OS. Other, bright
On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan wrote:
>
> On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
>>>
>>> I'm toying with the idea of a check_upgrade mode for the buildfarm client
>>> where it wouldn't do a git pull, but would report changes if the build
>>> result was different from the p
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane wrote:
> I can see both sides of this. It's definitely nice to get early warning
> when toolchain changes create new problems for Postgres, but it's not
> clear that the buildfarm is the best way to get such notifications.
Perhaps something as simple as
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm client
where it wouldn't do a git pull, but would report changes if the build
result was different from the previous result. You'd run this immediately
after pulling new changes into
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan wrote:
> There has to be something between "set in stone and never changes" and
> "auto-updates everything every 24 hours" that would suit us.
Well sure I could change the update frequency. But again, it seems
like delaying the inevitable.
> I'm to
On 07/29/2013 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in various different real-
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund wrote:
> Both the
> gcc 4.8 and the bison 3.0 problems are things the project needs to know
> about
Perl 5.18 too:
http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Andrew Dunstan writes:
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
>> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
>> I assumed that's a good thing -- the purpose of build farm is to test
>> PostgreSQL in various different real-life environments? Arch Linux is
>
On 2013-07-29 10:52:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> > e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> > (After fixing trivial conflicts in the latter).
>
> I've already spent more time on th
On 2013-07-29 10:46:41 -0400, Andrew Dunstan wrote:
>
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >Hi,
> >
> >>On 07/29/2013 01:05 AM, Tom Lane wrote:
> >>>Buildfarm member anchovy has been failing for the last couple of days,
> >>>evidently because its owner just couldn't wait to adopt biso
Andres Freund writes:
> FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> (After fixing trivial conflicts in the latter).
I've already spent more time on this than I wanted to, but just for
the archives' sake: neit
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old.
Hmm? Anchovy is upgrading automatica
Hi,
> On 07/29/2013 01:05 AM, Tom Lane wrote:
>> Buildfarm member anchovy has been failing for the last couple of days,
>> evidently because its owner just couldn't wait to adopt bison 3.0,
>> which is all of 3 days old.
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
On 2013-07-29 08:44:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> >> I'm not excited about breaking code in order to fix optimization bugs
> >> that are purely hypothetical (and for which there's no particular reason
> >> to believe that the
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
Reminder to buildfarm animal owners: if you upgrade software pl
Andres Freund writes:
> On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
>> I'm not excited about breaking code in order to fix optimization bugs
>> that are purely hypothetical (and for which there's no particular reason
>> to believe that the proposed change would fix them anyway). If we were
>> s
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> >> If we turn off the optimization, that will fix any other cases as well,
> >> no? So why would we risk breaking third-party code by back-porting the
> >> struct declaration
Andres Freund writes:
> On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
>> If we turn off the optimization, that will fix any other cases as well,
>> no? So why would we risk breaking third-party code by back-porting the
>> struct declaration changes?
> The -fno-agressive-loop thingie afaics only
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> The bottom line was:
> >>> It looks like our choices are (1) teach configure to enable
> >>> -fno-aggressive-loop-optimizat
Andres Freund writes:
> On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> The bottom line was:
>>> It looks like our choices are (1) teach configure to enable
>>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>>> or (2) back-port c
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > However, I comment on this mainly because anchovy has had issues with
> > > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > > Did you happen to res
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > However, I comment on this mainly because anchovy has had issues with
> > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > Did you happen to resolve or identify what is happening there..?
>
> Yeah, we kno
Stephen Frost writes:
> However, I comment on this mainly because anchovy has had issues with
> 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> Did you happen to resolve or identify what is happening there..?
Yeah, we know about that:
http://www.postgresql.org/message-id/
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Buildfarm member anchovy has been failing for the last couple of days,
[...]
> I'm thinking we should apply this to all supported branches, in case
> somebody gets the idea to build an older branch with bleeding-edge
> tools. Any objections?
Certainl
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
cubeparse.y:42.1-13: warning: deprecated directive, use '%name-prefix'
[-Wdeprecated]
%name-prefix="cube_y
I wrote:
> To produce a really useful cursor for this type of situation I think
> we would have to do something like this:
> #define YYLLOC_DEFAULT(Current, Rhs, N) \
> do { \
> int i;
> (Current) = -1; \
> for (i = 1; i <= (N); i++)
> {
> (Current)
In the just-committed patch for CREATE SCHEMA IF NOT EXISTS, there is
an error thrown by the grammar when IF NOT EXISTS is specified together
with any schema-element clauses. I thought it would make more sense for
the error cursor to point at the schema-element clauses, rather than at
the IF NOT E
The thing is I was in a project to develop a Fuzzy Database Management
System. We have to bring fuzzy logic to postgresql, there was a team
developing a software in java and the other developing in the
postgresql core. But I always think these were wrong, so I'm trying to
develop a library to do th
Andrew Dunstan wrote:
Werner Echezuria wrote:
Hi, I have a code in which I translate some code from sqlf to sql, but
when it comes to yy_parse the server crashes, I have no idea why,
because it works fine in other situations.
I don't understand why you're doing what you're doing this way.
Werner Echezuria wrote:
Hi, I have a code in which I translate some code from sqlf to sql, but
when it comes to yy_parse the server crashes, I have no idea why,
because it works fine in other situations.
I don't understand why you're doing what you're doing this way. Wouldn't
it be better
Hi, I have a code in which I translate some code from sqlf to sql, but
when it comes to yy_parse the server crashes, I have no idea why,
because it works fine in other situations.
This is the code (the problem is in parse_sqlf, when I call sqlf_yyparse):
#include "postgres.h"
#include "gram.h"
#
AIL PROTECTED]>
To: "Magnus Hagander" <[EMAIL PROTECTED]>
Cc: "PGSQL Hackers"
Sent: Sunday, March 18, 2007 2:06 AM
Subject: Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes:
Do you happen to have a 2.2 around so you can see what h
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Do you happen to have a 2.2 around so you can see what happens there? Or
> does someone else have that? So I know which version to test against...
2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to
test both last fall, and they genera
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Actually, looking at the GNU ftp site, there isn't even a version 2.2
>> available. There is a 2.1a which should have the fix (based on file
>> dates - they don't use branches or tags in their cvs repository).
>
> Huh? At
> http://f
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Actually, looking at the GNU ftp site, there isn't even a version 2.2
> available. There is a 2.1a which should have the fix (based on file
> dates - they don't use branches or tags in their cvs repository).
Huh? At
http://ftp.gnu.org/gnu/bison/
I see
Magnus Hagander wrote:
> I just tried building with Bison 2.1 on msvc, and it broke. For one
> thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
> obviously incorrect :-)
Actually, looking at the GNU ftp site, there isn't even a version 2.2
available. There is a 2.1a which should
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> The attached patch seems to fix the build issue. Does it seem
>> acceptable/the right thing to do?
>
> No, it seems pretty bletcherous.
That's kind of what I thought :-)
>> Another option would be to just reject both 2.0 and 2.1 a
Magnus Hagander <[EMAIL PROTECTED]> writes:
> The attached patch seems to fix the build issue. Does it seem
> acceptable/the right thing to do?
No, it seems pretty bletcherous.
> Another option would be to just reject both 2.0 and 2.1 as broken to
> build pg with, I guess...
In bison 2.3 (which
Magnus Hagander wrote:
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)
But the generated C file also does not compile causing the error on
http://msdn2.microsoft.com/en-us/library/93az
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)
But the generated C file also does not compile causing the error on
http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc
d
Due to the bug in bison 2.1, I always use version 1.875:
http://www.mail-archive.com/bug-bison@gnu.org/msg00718.html
""Christopher Kings-Lynne"" <[EMAIL PROTECTED]>
> What version of Bison is currently required to compile HEAD? 1.75
> doesn't seem to work...
>
> ---(en
Christopher Kings-Lynne wrote:
What version of Bison is currently required to compile HEAD? 1.75
doesn't seem to work...
Bison >= 1.875 has been required for years. That hasn't changed.
cheers
andrew
---(end of broadcast)---
TIP 3: Have you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> What version of Bison is currently required to compile HEAD? 1.75
> doesn't seem to work...
1.875
Search for Bison here:
http://projects.commandprompt.com/public/pgsql/browser/trunk/pgsql/doc/src/sgml/installation.sgml
- --
Greg Sabino Mullane
What version of Bison is currently required to compile HEAD? 1.75
doesn't seem to work...
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ECTED]>,
> PostgreSQL-development
> Subject: Re: [HACKERS] bison version
>
> ohp@pyrenet.fr writes:
> > Here's my make.log FWIW...
> > ...
> > gram.y:7074.27-7077.33: warning: useless rule: b_expr: b_expr IS OF '('
> > type_list
ohp@pyrenet.fr writes:
> Here's my make.log FWIW...
> ...
> gram.y:7074.27-7077.33: warning: useless rule: b_expr: b_expr IS OF '('
> type_list ')'
> gram.y:7078.27-7081.33: warning: useless rule: b_expr: b_expr IS NOT OF '('
> type_list ')'
> gmake[3]: *** [parse.h] Segmentation Fault (core dump
Hi Stefan,
Here's my make.log FWIW...
TIA
On Sat, 10 Jun 2006, Stefan Kaltenbrunner wrote:
> Date: Sat, 10 Jun 2006 21:10:09 +0200
> From: Stefan Kaltenbrunner <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] bison versio
ohp@pyrenet.fr wrote:
> Hi,
>
> I'd like to check 2 things:
>
> What's the bison version required to compile gram.y ?
> Trying to set up a build farm machine, it seems I can't compile with bison
> 2.1 ...
1.875
> Also where is the documentation page that gives postgresql limits (number
> of col
ohp@pyrenet.fr wrote:
> Hi,
>
> I'd like to check 2 things:
>
> What's the bison version required to compile gram.y ?
> Trying to set up a build farm machine, it seems I can't compile with bison
> 2.1 ...
2.1 should work fine - there are a number of boxes on the buildfarm
running with that versi
Hi,
I'd like to check 2 things:
What's the bison version required to compile gram.y ?
Trying to set up a build farm machine, it seems I can't compile with bison
2.1 ...
Also where is the documentation page that gives postgresql limits (number
of column/table max size of col)
Many thanks
--
Josh Berkus writes:
> Might I suggest changing the wording in the final release, then? The warning
> sure looked dangerous;
It only looks dangerous to those who don't actually read the full text of
the message.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadc
Tom,
> > Really? 'cause I got the warning from the Beta4 tarball.
>
> If you mean the configure warning, sure, but the build won't fail.
Might I suggest changing the wording in the final release, then? The warning
sure looked dangerous; I aborted the build and went looking for bison 1.875
bi
Josh Berkus wrote:
Peter,
I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't
afford
to upgrade right now. Does such an animal exist? Help!
Install it from source if you cannot find a package.
Hmmm ... still getting the "Bison Too Old" warning messag
Josh Berkus <[EMAIL PROTECTED]> writes:
>> No, because it only matters to people who build from a CVS pull instead
>> of using a tarball. I'd think most of the people in the first category
>> have already dealt with the issue...
> Really? 'cause I got the warning from the Beta4 tarball.
If you
TOm,
> No, because it only matters to people who build from a CVS pull instead
> of using a tarball. I'd think most of the people in the first category
> have already dealt with the issue...
Really? 'cause I got the warning from the Beta4 tarball.
--
-Josh Berkus
Aglio Database Solutions
Josh Berkus <[EMAIL PROTECTED]> writes:
> (I predict that we're going to get many more questions about Bison after we
> release 7.4, since many major Linux distros don't yet include 1.875)
No, because it only matters to people who build from a CVS pull instead
of using a tarball. I'd think most
On Fri, 17 Oct 2003 09:43 am, Josh Berkus wrote:
> (I predict that we're going to get many more questions about Bison after we
> release 7.4, since many major Linux distros don't yet include 1.875)
You only need bison if you are building from CVS - tarballs include the bison
output files (AFAIK -
Peter,
> If you installed from source into /usr/local/bin and you have an older
> version in /usr/bin, you may need to run 'hash -r' or 'rehash' to make the
> shell forget about the old installation in the path.
Yeah, that was it. Thanks!
(I predict that we're going to get many more questions a
Josh Berkus writes:
> Hmmm ... still getting the "Bison Too Old" warning message. How can I tell
> where Postgres is looking for Bison?
checking for bison... bison -y
^
I tells you right there.
If you installed from source into /usr/local/bin and you have an older
vers
Peter,
> > I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't
afford
> > to upgrade right now. Does such an animal exist? Help!
>
> Install it from source if you cannot find a package.
Hmmm ... still getting the "Bison Too Old" warning message. How can I tell
where Postg
Peter Eisentraut wrote:
Josh Berkus writes:
I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford
to upgrade right now. Does such an animal exist? Help!
Install it from source if you cannot find a package.
or build from an SRPM - the dependencies are quite m
Josh Berkus writes:
> I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford
> to upgrade right now. Does such an animal exist? Help!
Install it from source if you cannot find a package.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadc
Folks,
I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford
to upgrade right now. Does such an animal exist? Help!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searc
For those using Linux, the RPMs at:
http://services.csl.co.uk/postgresql/
are probably handy.
L.
Bruce Momjian writes:
> Sorry, I meant bison 1.875 is now required, not 1.85.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] |
Guys, for your convenience i've put online a source RPM for Bison
1.875 along with binary RPMs for Redhat 7.2, 7.3 and 8.0. Hunting
around the net i didn't find any existing Bison >= 1.50 RPMs, so this
should be useful for those compiling PostgreSQL (ECPG in particular)
from the CVS source:
http:
bigapple wrote:
> hi,
> When I check out the pgsql from cvs and I complile it, an error occured .
>
> dir: pgsql/src/interfaces/ecpg/preproc
> bison -y -d preproc.y
> erro information:
> preproc.y:5559: fatal error: maximum table size (32767) exceeded.
>
You need at least version 1.5 of biso
On Mon, 2002-12-09 at 01:58, bigapple wrote:
> When I check out the pgsql from cvs and I complile it, an error occured .
>
> dir: pgsql/src/interfaces/ecpg/preproc
> bison -y -d preproc.y
> erro information:
> preproc.y:5559: fatal error: maximum table size (32767) exceeded.
You need to use B
hi,
When I check out the pgsql from cvs and I complile it, an error occured .
dir: pgsql/src/interfaces/ecpg/preproc
bison -y -d preproc.y
erro information:
preproc.y:5559: fatal error: maximum table size (32767) exceeded.
However, I used the source from the ftp, find preproc.c in there. gma
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > let me know if there are any problems with it
>
>
> Other than the fact that it's about a factor of 16 slower than bison
> 1.28, while not offering any substantial gain in functionality? If I
> were a Bison maintainer, I'd
let me know if there are any problems with it
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Oh, that's right. I had forgotten that it wasn't for general PostgreSQL
use. Since it's a ecpg deal only, I guess I remove my objection.
Greg
On Thu, 2002-10-10 at 09:18, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > Can we please hold off until bison 1.50 becomes a defacto
Greg Copeland wrote:
-- Start of PGP signed section.
> Can we please hold off until bison 1.50 becomes a defacto? It will be a
> matter of weeks before distros offer this as an upgrade package let
> alone months before distros offer this as a standard. Seems like these
> changes are ideal for a
Greg Copeland <[EMAIL PROTECTED]> writes:
> Can we please hold off until bison 1.50 becomes a defacto?
We don't have a whole lot of choice, unless you prefer releasing a
broken or crippled ecpg with 7.3.
In practice this only affects people who pull sources from CVS, anyway.
If you use a tarball
Can we please hold off until bison 1.50 becomes a defacto? It will be a
matter of weeks before distros offer this as an upgrade package let
alone months before distros offer this as a standard. Seems like these
changes are ideal for a release after next (7.5/7.6) as enough time will
of gone by f
Hi,
I just learned that bison 1.50 was released on Oct. 5th and it indeed
compiles ecpg just nicely on my machine. Could we please install this on
our main machine and merge the ecpg.big branch back into main?
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GN
Bruce Momjian writes:
> This may be a case where we have to do some beta testing on our own. I
> will grab the bison beta myself for my machine.
I imagine that bison doesn't get a lot of beta testing, since people don't
have a whole bunch of production grammars lying around that they want to
upg
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, now that _a_ bison exists that works, how does this effect our
> > release? I don't see preproc.[ch] in CVS. Do we need this new bison
> > version on postgresql.org because Marc generates these as part of his
> > install script?
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, now that _a_ bison exists that works, how does this effect our
> release? I don't see preproc.[ch] in CVS. Do we need this new bison
> version on postgresql.org because Marc generates these as part of his
> install script?
I don't think we want a
OK, now that _a_ bison exists that works, how does this effect our
release? I don't see preproc.[ch] in CVS. Do we need this new bison
version on postgresql.org because Marc generates these as part of his
install script?
-
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
>> BTW, I spent some time looking at the problem, and it seems the issue
>> is not overrun of any bison internal table, but failure to compress the
>> resulting "action table" into 32K entries.
On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
> BTW, I spent some time looking at the problem, and it seems the issue
> is not overrun of any bison internal table, but failure to compress the
> resulting "action table" into 32K entries. This means that the required
Ouch! This of cour
Michael Meskes <[EMAIL PROTECTED]> writes:
> I just got the latest beta and it compiles ecpg grammar correctly!
This is good. Any word on when it will go to an official release?
BTW, I spent some time looking at the problem, and it seems the issue
is not overrun of any bison internal table, but
I just got the latest beta and it compiles ecpg grammar correctly! I had
to make one change to my source though as bison no longer accepts a comma inside the
token list.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
-
Hi,
I talked to one of the bison guys and he told me where to find a beta
version of bison 1.49. And this one translates the grammar without a
problem, no more table overflow. So once they will release the
new bison we should be able to expand our grammar.
Michael
--
Michael Meskes
[EMAIL PROTE
1 - 100 of 101 matches
Mail list logo
