Re: [BUGS] BUG #1962: ECPG and VARCHAR
Michael Fuhr wrote: > On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote: > > ecpg in 8.0.4 seems not to like the macros. I get the same error, > > but not if I do this: > > > > VARCHAR t[256]; > > VARCHAR o[256]; > > > > ecpg in 8.1beta3 works either way. > > This appears to be the guilty commit, which was made to 7.4, 8.0, > and HEAD (8.1): > > http://archives.postgresql.org/pgsql-committers/2005-08/msg00266.php > > It was recently fixed in HEAD only: > > http://archives.postgresql.org/pgsql-committers/2005-10/msg00043.php Good catch! I have backpatched these fixes to the 8.0 and 7.4 branches as you suggested, (identical) patches attached. The big problem is that we might not make releases on these branches for months, so anyone needing the fix should download CVS for those branches. -- 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, Pennsylvania 19073 Index: src/interfaces/ecpg/preproc/preproc.y === RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v retrieving revision 1.303.4.4 diff -c -c -r1.303.4.4 preproc.y *** src/interfaces/ecpg/preproc/preproc.y 24 Aug 2005 10:35:12 - 1.303.4.4 --- src/interfaces/ecpg/preproc/preproc.y 14 Oct 2005 01:47:05 - *** *** 5142,5149 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* if (strcmp(length, "0") == 0)*/ ! if (atoi(length) <= 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) --- 5142,5149 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* cannot check for atoi <= 0 because a defined constant will yield 0 here as well */ ! if (atoi(length) < 0 || strcmp(length, "0") == 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) Index: src/interfaces/ecpg/preproc/preproc.y === RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v retrieving revision 1.263.2.20 diff -c -c -r1.263.2.20 preproc.y *** src/interfaces/ecpg/preproc/preproc.y 24 Aug 2005 10:35:54 - 1.263.2.20 --- src/interfaces/ecpg/preproc/preproc.y 14 Oct 2005 01:47:43 - *** *** 5121,5128 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* if (strcmp(length, "0") == 0)*/ ! if (atoi(length) <= 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) --- 5121,5128 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* cannot check for atoi <= 0 because a defined constant will yield 0 here as well */ ! if (atoi(length) < 0 || strcmp(length, "0") == 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale
This has been saved for the 8.2 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Tom Lane wrote: > "Devrim GUNDUZ" <[EMAIL PROTECTED]> writes: > > http://sourceware.org/bugzilla/long_list.cgi?buglist=1354 > > So it is PostgreSQL's bug or Glibc's? > > Just offhand, iwchareq() seems several bricks shy of a load: > > /* > * if one of them is an ASCII while the other is not, then they must > * be different characters > */ > else if ((unsigned char) *p1 < CHARMAX || (unsigned char) *p2 < CHARMAX) > return (0); > > This test is wrong per Jakub's observation. Also, the code right below > that is using tolower() not towlower() on wide characters, which seems > pretty wrong. For that matter, towlower would be wrong too :-( because > there is no certainty that libc's idea of wide characters is the same as > pg_mb2wchar_with_len's. > > So yeah, ILIKE looks just about completely broken for multibyte encodings. > Maybe it would be best to pass both strings through lower() and then > do a normal LIKE comparison? > > The regexp code doesn't look better, btw, just differently broken ... > > regards, tom lane > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > -- 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote: >> Basically, DECLARE introduces a new name scope that wouldn't be there >> if you didn't say DECLARE. Without some bizarre reinterpretation of the >> meaning of a DECLARE at the start of a function, variables automatically >> created by plpgsql are going to be in an outer scope surrounding that of >> the first DECLARE. > Another possibility is tracking what level sub-block something is in, > and using that to determine if the top-most declare in a function is > over-writing something. BTW, another issue here is that if we did merge the first DECLARE with the scope of auto-declared variables, it would be a non backwards compatible change. Right now you can do, say, declare found int; and it'll override the standard FOUND variable. If we change this then you'd get an error. (Of course, it could be argued that that would be a Good Thing. But it would inhibit us from adding new auto-declared variables that are less central to the language than FOUND, because of the risk of breaking existing code.) regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope
On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > Based on all that, I would certainly be in favor of throwing a warning > > if you over-define something, since 99% of the time it's a mistake. Is > > that possible with the current checking we do at compile time? > > Without having looked at the code, I imagine the problem is that we > can't tell this situation from an ordinary nested DECLARE block, > that is > > declare x int; > begin > ... > declare x float; > begin > ... > > The above is legal code and I don't think we should throw a warning for > it. > > Basically, DECLARE introduces a new name scope that wouldn't be there > if you didn't say DECLARE. Without some bizarre reinterpretation of the > meaning of a DECLARE at the start of a function, variables automatically > created by plpgsql are going to be in an outer scope surrounding that of > the first DECLARE. Yeah, I agree that in the legitimate case it makes much less sense to throw an error. Are blocks that aren't explicitely labled assigned a machine-generated label? If so then it should be possible to tell if something is in the outer-most block or if it's part of the function declaration itself. But I have no idea how difficult it would be to do that. Another possibility is tracking what level sub-block something is in, and using that to determine if the top-most declare in a function is over-writing something. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1962: ECPG and VARCHAR
On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote: > ecpg in 8.0.4 seems not to like the macros. I get the same error, > but not if I do this: > > VARCHAR t[256]; > VARCHAR o[256]; > > ecpg in 8.1beta3 works either way. This appears to be the guilty commit, which was made to 7.4, 8.0, and HEAD (8.1): http://archives.postgresql.org/pgsql-committers/2005-08/msg00266.php It was recently fixed in HEAD only: http://archives.postgresql.org/pgsql-committers/2005-10/msg00043.php -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1815: ECPGdebug causes crash on Windows XP
Thanks, I have added an additional sentence to that section outlining the specific items that should match --- patch attached. --- William ZHANG wrote: > I remember that I have posted the answer to pgsql.bugs, > but now it can only be found here: > > http://www.talkaboutdatabases.com/group/pgsql.bugs/messages/2346.html > > Do not know what's wrong with the mail list or my mails. > > "Bruce Momjian" wrote > > > > Ah, I have found the cause of the crash, and added documentation about > > the cause: > > > > On Win32, if the ecpg libraries and application are > > compiled with different flags, this function call will crash the > > application because the internal representation of the FILE > > pointers differ. > > > > While such a mismatch is a problem on all platforms, it is more common > > on Win32 where the FILE structure changes for debug, for example. > > > > -- > - > > > > Michael Meskes wrote: > > > On Mon, Aug 15, 2005 at 07:39:42PM +0800, William ZHANG wrote: > > > > Yes. It is reproducible. But it works well in MinGW. > > > > Is there sth. wrong with the import library lib\ms\libecpg.lib or > > > > lib\libecpg.dll? > > > > > > > > "Joshua Masiko" <[EMAIL PROTECTED]> > > > > wrote:[EMAIL PROTECTED] > > > > > > > > > > ntdll.dll!7c918fea() > > > > > ntdll.dll!7c9106eb() > > > > > ntdll.dll!7c90104b() > > > > > msvcrt.dll!77c3b90d() > > > > > msvcrt.dll!77c420e7() > > > > > libecpg.dll!6d0c7471() > > > > >> ecpgtest.exe!main(int argc=1, char * * > > > > > argv=0x003c0d10) Line 5 + 0xc C > > > > > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C > > > > > kernel32.dll!7c816d4f() > > > > > kernel32.dll!7c8399f3() > > > > > > > > > > > > > > > The offending line in ecpgtest.pgc is > > > > > > > > > > ECPGdebug(1,stderr); > > > > > > > > > > I get the same result even if I use a file handle > > > > > obtained by using fopen > > > > > > Could someone with access to a Windows system have a look at this? I do > > > not have one atm. In particular I'd like to know whether it makes a > > > difference if your compiled ecpg with threading enabled or not. After > > > all without threading the function called does not much, just changing > > > two variables and logging the change. > > > > > > Michael > > > -- > > > Michael Meskes > > > Email: Michael at Fam-Meskes dot De, Michael at Meskes dot > (De|Com|Net|Org) > > > ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] > > > Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! > > > > > > ---(end of broadcast)--- > > > TIP 2: Don't 'kill -9' the postmaster > > > > > > > -- > > 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, Pennsylvania > 19073 > > > > ---(end of broadcast)--- > > TIP 6: explain analyze is your friend > > > > > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > -- 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, Pennsylvania 19073 Index: doc/src/sgml/ecpg.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v retrieving revision 1.67 diff -c -c -r1.67 ecpg.sgml *** doc/src/sgml/ecpg.sgml 25 Sep 2005 03:12:13 - 1.67 --- doc/src/sgml/ecpg.sgml 13 Oct 2005 17:45:12 - *** *** 1612,1618 On Win32, if the ecpg libraries and an application are compiled with different flags, this function call will crash the application because the internal representation of the ! FILE pointers differ. --- 1612,1620 On Win32, if the ecpg libraries and an application are compiled with different flags, this function call will crash the application because the internal representation of the ! FILE pointers differ. Specifically, ! threading/non-threading, release/debug, and static/dynamic flags should ! be the same for the library and all applications using that library. Index: doc/src/sgml/libpq.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.191 diff -c -c -r1.191 libpq.sgml *** doc/src/sgml/libpq.sgml 25 Sep 2005 03:12:13 - 1.191 --- doc/src/sgml/libpq.sgml 1
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Based on all that, I would certainly be in favor of throwing a warning > if you over-define something, since 99% of the time it's a mistake. Is > that possible with the current checking we do at compile time? Without having looked at the code, I imagine the problem is that we can't tell this situation from an ordinary nested DECLARE block, that is declare x int; begin ... declare x float; begin ... The above is legal code and I don't think we should throw a warning for it. Basically, DECLARE introduces a new name scope that wouldn't be there if you didn't say DECLARE. Without some bizarre reinterpretation of the meaning of a DECLARE at the start of a function, variables automatically created by plpgsql are going to be in an outer scope surrounding that of the first DECLARE. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope
On Thu, Oct 13, 2005 at 10:38:36AM -0400, Bruce Momjian wrote: > Karl O. Pinc wrote: > > > > On 10/12/2005 10:32:20 PM, Bruce Momjian wrote: > >We tend to follow the C conventions, so perhaps we > > > should > > > throw a warning, but I can't think of any cases where we throw a > > > warning > > > in plpgsql because we compile it once on first call. > > > > > > I am thinking this falls in the "don't do that" category. > > > > Fair enough. At the same time it sure would be nice if > > plpgsql actually compiled (and parsed SQL) at > > function definition time, even when the result is thrown away. > > I'm building a big system and it's quite annoying > > to get syntax errors, IIRC, > > in code months after writing it, just because it took > > me that long to get around to exercising a particular > > IF statement. > > 8.0 has this improvement: > > * Do minimal syntax checking of PL/pgSQL functions at creation time (Tom) >This allows us to catch simple syntax errors sooner. Based on all that, I would certainly be in favor of throwing a warning if you over-define something, since 99% of the time it's a mistake. Is that possible with the current checking we do at compile time? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1959: readline error exiting psql
"David Wheeler" <[EMAIL PROTECTED]> writes: > Hrm. No, I just went in and ran a query, then quit, and then it said: > psql(14102) malloc: *** error for object 0x1807000: incorrect checksum for > freed object - object was probably modified after being freed, break at > szone_error to debug > psql(14102) malloc: *** set a breakpoint in szone_error to debug > zsh: segmentation fault /usr/local/pgsql/bin/psql -U postgres -d sharky Are you sure this bug report shouldn't be directed to Apple? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1962: ECPG and VARCHAR
On Thu, Oct 13, 2005 at 02:24:27PM +0100, Charles Wegrzyn wrote: > I have code that under 8.0.3 works: > > VARCHAR t[MAX_TENANT_SIZE+1]; > VARCHAR o[MAX_OID_SIZE+1]; > > In 8.0.4 I found this throws an error during the ecpg step: > > tenant.ec:375: ERROR: pointer to varchar are not implemented > tenant.ec:376: ERROR: pointer to varchar are not implemented ecpg in 8.0.4 seems not to like the macros. I get the same error, but not if I do this: VARCHAR t[256]; VARCHAR o[256]; ecpg in 8.1beta3 works either way. -- Michael Fuhr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] building Postgresql 7.3.10 on Mac OS X 10.4
"Peter Bazeley" <[EMAIL PROTECTED]> writes: > I am trying to build Postgresql 7.3.10 on Mac OS X 10.4 and am getting a = > couple errors related to bootstrap libraries. These are occuring during = > make -C bootstrap all. Here is the output:=20 > make -C bootstrap all=20 > gcc -traditional-cpp -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes= > -Wmissing-declarations -I. -I../../../src/include -I/sw/include/ -c -o = For more recent versions of OS X (since 10.2 I think), you need -no-cpp-precomp instead of -traditional-cpp. PG 7.3.* is too old to know about that ... you can probably fix this in src/template/darwin, but it may not be the last such gotcha. Are you sure you want such an old PG version? I'd currently recommend the 8.0 branch for production and 8.1 for development. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope
Bruce Momjian writes: > Karl O. Pinc wrote: >> Fair enough. At the same time it sure would be nice if >> plpgsql actually compiled (and parsed SQL) at >> function definition time, even when the result is thrown away. > 8.0 has this improvement: > * Do minimal syntax checking of PL/pgSQL functions at creation time (Tom) >This allows us to catch simple syntax errors sooner. 8.1 does more in that line (thanks to Neil). regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] building Postgresql 7.3.10 on Mac OS X 10.4
On 10/13/05, Bruce Momjian wrote: > I would get a newer version of PostgreSQL, either 8.0.X or 8.1beta. I > am sure that wil work. Yes, I discontinued support for the 7.3.x series on Mac OS X 10.4 in the Fink packages for just this reason; it's not worth trying to backport the changes from the 7.4+ series that make it possible to repair these issues. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1961: Can not deinstall PostgreSQL
Tobias Lana wrote: Tried to update Version 7.03.02 to 8.0.1.1. During the deinstallation of 7.03.02, following popup came up: -- Error 1327, Invalid Drive W: -- and the deinstallation aborted. How can I deinstall the old driver ? 1. Is this the ODBC driver you are talking about? 2. I take it you used to have a drive W: but now don't. If you use something like "SUBST W: C:\some_folder" can you uninstall? 3. If all else fails, I believe you can delete the ODBC driver by removing the files and removing the registry keys by hand. http://archives.postgresql.org/pgsql-odbc/2005-05/msg00018.php HTH -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1958: Postmaster doesn't close open file handles on startup
"Menno Smits" <[EMAIL PROTECTED]> writes: > The postmaster process doesn't close open file handles/sockets when it > daemonises. This means it inherits all open file handles that the parent > process had. This can lead to strange side effects because postgres will > hold sockets and files that it really shouldn't. I think this is a bug in whatever you are using to launch the postmaster, not a bug in the postmaster. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope
Karl O. Pinc wrote: > > On 10/12/2005 10:32:20 PM, Bruce Momjian wrote: >We tend to follow the C conventions, so perhaps we > > should > > throw a warning, but I can't think of any cases where we throw a > > warning > > in plpgsql because we compile it once on first call. > > > > I am thinking this falls in the "don't do that" category. > > Fair enough. At the same time it sure would be nice if > plpgsql actually compiled (and parsed SQL) at > function definition time, even when the result is thrown away. > I'm building a big system and it's quite annoying > to get syntax errors, IIRC, > in code months after writing it, just because it took > me that long to get around to exercising a particular > IF statement. 8.0 has this improvement: * Do minimal syntax checking of PL/pgSQL functions at creation time (Tom) This allows us to catch simple syntax errors sooner. I assume you are running an earlier version of PostgreSQL. -- 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1958: Postmaster doesn't close open file handles on
I guess we could, though I have rarely seen programs do this. They usually just to the std* descriptors. --- Menno Smits wrote: > > The following bug has been logged online: > > Bug reference: 1958 > Logged by: Menno Smits > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: Linux (Fedora Core 3) > Description:Postmaster doesn't close open file handles on startup > Details: > > The postmaster process doesn't close open file handles/sockets when it > daemonises. This means it inherits all open file handles that the parent > process had. This can lead to strange side effects because postgres will > hold sockets and files that it really shouldn't. > > The following short Python script demonstrates the problem. It starts > listening on TCP port and then restarts postgresql. Run with "python >
Re: [BUGS] BUG #1953: trigger action on delete
On 10/12/2005 11:20 PM, Tom Lane wrote: I wrote: Bruce Momjian writes: It isn't so much the alphabetical order, since there is only one trigger, but the concept that we now group all the _before_ triggers before the _after_ triggers. But we've always done that. Has the example ever been correct? I was intending to try it on older versions, but I don't actually think it's ever acted like the docs said. After digging in the CVS archives, I find that it did work like that up till this 7.0 patch: 1999-09-29 12:05 wieck This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. So the example was probably correct when put in, but no one's noticed it was wrong since 7.0 :-( IIRC we had discussed that stuff during the RI development and decided to have ALL _after_ triggers get fired by the deferred queue after the statement. The example deletes multiple rows in one statement. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1960: Respons(Binary) is not correctly by PQexecParams
The following bug has been logged online: Bug reference: 1960 Logged by: tadayoshi sato Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: WindowsXp ,Linux (redhat9) Description:Respons(Binary) is not correctly by PQexecParams Details: The result is made a binary with PQExecParams and it doesn't respond the data of Varchar (The server: EUC-JP and client: SHIFTJIS) correctly. The cause seems it is because the character string of the argument to pg_server_to_client of the average of pq_sendtext is not NULL stop. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] building Postgresql 7.3.10 on Mac OS X 10.4
I would get a newer version of PostgreSQL, either 8.0.X or 8.1beta. I am sure that wil work. --- Peter Bazeley wrote: > Hello > I am trying to build Postgresql 7.3.10 on Mac OS X 10.4 and am getting a > couple errors related to bootstrap libraries. These are occuring during make > -C bootstrap all. Here is the output: > make -C bootstrap all > gcc -traditional-cpp -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes > -Wmissing-declarations -I. -I../../../src/include -I/sw/include/ -c -o > bootparse.o bootparse.c > y.tab.c:928: warning: no previous prototype for 'Int_yyparse' > bootparse.y: In function 'Int_yyparse': > bootparse.y:273: error: stray '##' in program > bootparse.y:273: error: 'T_' undeclared (first use in this function) > bootparse.y:273: error: (Each undeclared identifier is reported only once > bootparse.y:273: error: for each function it appears in.) > bootparse.y:273: error: parse error before 'IndexElem' > In file included from bootparse.y:341: > lex.Int_yy.c: At top level: > lex.Int_yy.c:1122: warning: 'Int_yy_get_next_buffer' was used with no > prototype before its definition > lex.Int_yy.c:1254: warning: 'Int_yy_get_previous_state' was used with no > prototype before its definition > lex.Int_yy.c:1292: warning: 'Int_yy_try_NUL_trans' was used with no prototype > before its definition > lex.Int_yy.c:1440: warning: no previous prototype for 'Int_yyrestart' > lex.Int_yy.c:1455: warning: no previous prototype for > 'Int_yy_switch_to_buffer' > lex.Int_yy.c:1486: warning: no previous prototype for > 'Int_yy_load_buffer_state' > lex.Int_yy.c:1498: warning: no previous prototype for 'Int_yy_create_buffer' > lex.Int_yy.c:1529: warning: no previous prototype for 'Int_yy_delete_buffer' > lex.Int_yy.c:1555: warning: no previous prototype for 'Int_yy_init_buffer' > lex.Int_yy.c:1582: warning: no previous prototype for 'Int_yy_flush_buffer' > lex.Int_yy.c:1613: warning: no previous prototype for 'Int_yy_scan_buffer' > lex.Int_yy.c:1651: warning: no previous prototype for 'Int_yy_scan_string' > lex.Int_yy.c:1668: warning: no previous prototype for 'Int_yy_scan_bytes' > lex.Int_yy.c:1762: warning: 'Int_yy_fatal_error' was used with no prototype > before its definition > lex.Int_yy.c:1826: warning: 'Int_yy_flex_alloc' was used with no prototype > before its definition > lex.Int_yy.c:1836: warning: 'Int_yy_flex_realloc' was used with no prototype > before its definition > lex.Int_yy.c:1854: warning: 'Int_yy_flex_free' was used with no prototype > before its definition > make[3]: *** [bootparse.o] Error 1 > make[2]: *** [bootstrap-recursive] Error 2 > make[1]: *** [all] Error 2 > make: *** [all] Error 2 > Any suggestions? > Thanks, > Peter Bazeley > > Peter Bazeley, M.Sc. > Database Specialist / Research > Bioinformatics and Proteomics / Genomics > Medical University of Ohio > Toledo, Ohio 43614-5806 > > > > > On June 8, 2005, the Medical College of Ohio's name changed to the Medical > University of Ohio. > > Please note that any contacts stored in your personal address book with the > extension of mco.edu should now be changed to meduohio.edu to avoid any > interruptions in email delivery. > > CONFIDENTIALITY NOTICE: > This e-mail message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please contact the sender > by reply e-mail and destroy all copies of the original message. > <<<>>> -- 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share
On 10/12/2005 10:32:20 PM, Bruce Momjian wrote: We tend to follow the C conventions, so perhaps we should throw a warning, but I can't think of any cases where we throw a warning in plpgsql because we compile it once on first call. I am thinking this falls in the "don't do that" category. Fair enough. At the same time it sure would be nice if plpgsql actually compiled (and parsed SQL) at function definition time, even when the result is thrown away. I'm building a big system and it's quite annoying to get syntax errors, IIRC, in code months after writing it, just because it took me that long to get around to exercising a particular IF statement. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] building Postgresql 7.3.10 on Mac OS X 10.4
Hello I am trying to build Postgresql 7.3.10 on Mac OS X 10.4 and am getting a couple errors related to bootstrap libraries. These are occuring during "make -C bootstrap all". Here is the output: make -C bootstrap all gcc -traditional-cpp -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -I/sw/include/ -c -o bootparse.o bootparse.c y.tab.c:928: warning: no previous prototype for 'Int_yyparse' bootparse.y: In function 'Int_yyparse': bootparse.y:273: error: stray '##' in program bootparse.y:273: error: 'T_' undeclared (first use in this function) bootparse.y:273: error: (Each undeclared identifier is reported only once bootparse.y:273: error: for each function it appears in.) bootparse.y:273: error: parse error before 'IndexElem' In file included from bootparse.y:341: lex.Int_yy.c: At top level: lex.Int_yy.c:1122: warning: 'Int_yy_get_next_buffer' was used with no prototype before its definition lex.Int_yy.c:1254: warning: 'Int_yy_get_previous_state' was used with no prototype before its definition lex.Int_yy.c:1292: warning: 'Int_yy_try_NUL_trans' was used with no prototype before its definition lex.Int_yy.c:1440: warning: no previous prototype for 'Int_yyrestart' lex.Int_yy.c:1455: warning: no previous prototype for 'Int_yy_switch_to_buffer' lex.Int_yy.c:1486: warning: no previous prototype for 'Int_yy_load_buffer_state' lex.Int_yy.c:1498: warning: no previous prototype for 'Int_yy_create_buffer' lex.Int_yy.c:1529: warning: no previous prototype for 'Int_yy_delete_buffer' lex.Int_yy.c:1555: warning: no previous prototype for 'Int_yy_init_buffer' lex.Int_yy.c:1582: warning: no previous prototype for 'Int_yy_flush_buffer' lex.Int_yy.c:1613: warning: no previous prototype for 'Int_yy_scan_buffer' lex.Int_yy.c:1651: warning: no previous prototype for 'Int_yy_scan_string' lex.Int_yy.c:1668: warning: no previous prototype for 'Int_yy_scan_bytes' lex.Int_yy.c:1762: warning: 'Int_yy_fatal_error' was used with no prototype before its definition lex.Int_yy.c:1826: warning: 'Int_yy_flex_alloc' was used with no prototype before its definition lex.Int_yy.c:1836: warning: 'Int_yy_flex_realloc' was used with no prototype before its definition lex.Int_yy.c:1854: warning: 'Int_yy_flex_free' was used with no prototype before its definition make[3]: *** [bootparse.o] Error 1 make[2]: *** [bootstrap-recursive] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Any suggestions? Thanks, Peter Bazeley Peter Bazeley, M.Sc.Database Specialist / ResearchBioinformatics and Proteomics / GenomicsMedical University of OhioToledo, Ohio 43614-5806 On June 8, 2005, the Medical College of Ohio's name changed to the Medical University of Ohio. Please note that any contacts stored in your personal address book with the extension of mco.edu should now be changed to meduohio.edu to avoid any interruptions in email delivery. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
[BUGS] BUG #1961: Can not deinstall PostgreSQL
The following bug has been logged online: Bug reference: 1961 Logged by: Tobias Lana Email address: [EMAIL PROTECTED] PostgreSQL version: 7.03.02 Operating system: Win 2000 Server Description:Can not deinstall PostgreSQL Details: Tried to update Version 7.03.02 to 8.0.1.1. During the deinstallation of 7.03.02, following popup came up: -- Error 1327, Invalid Drive W: -- and the deinstallation aborted. How can I deinstall the old driver ? Best Regards tl ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1962: ECPG and VARCHAR
The following bug has been logged online: Bug reference: 1962 Logged by: Charles Wegrzyn Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Linux : 2.6.13-r4 Description:ECPG and VARCHAR Details: I have code that under 8.0.3 works: VARCHAR t[MAX_TENANT_SIZE+1]; VARCHAR o[MAX_OID_SIZE+1]; In 8.0.4 I found this throws an error during the ecpg step: tenant.ec:375: ERROR: pointer to varchar are not implemented tenant.ec:376: ERROR: pointer to varchar are not implemented ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1958: Postmaster doesn't close open file handles on startup
The following bug has been logged online: Bug reference: 1958 Logged by: Menno Smits Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Linux (Fedora Core 3) Description:Postmaster doesn't close open file handles on startup Details: The postmaster process doesn't close open file handles/sockets when it daemonises. This means it inherits all open file handles that the parent process had. This can lead to strange side effects because postgres will hold sockets and files that it really shouldn't. The following short Python script demonstrates the problem. It starts listening on TCP port and then restarts postgresql. Run with "python
[BUGS] BUG #1959: readline error exiting psql
The following bug has been logged online: Bug reference: 1959 Logged by: David Wheeler Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1b3 Operating system: Mac OS X 10.4 "Tiger" Description:readline error exiting psql Details: At least it doesn't segfault anymore, but when exiting psql with 8.1b3 on Mac OS X 10.4 "Tiger" with Apple's wacko readline library, I get the following error: could not save history to file "/Users/david/.psql_history": Invalid argument Hrm. No, I just went in and ran a query, then quit, and then it said: psql(14102) malloc: *** error for object 0x1807000: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug psql(14102) malloc: *** set a breakpoint in szone_error to debug zsh: segmentation fault /usr/local/pgsql/bin/psql -U postgres -d sharky Bummer. The weird thing is that the query I ran does show up in the history if I go into psql again. Very odd. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
