Re: [HACKERS] Minor problem with Makefile.shlib
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I submitted a patch to fix this on October 21st, but it has not been applied (in common with several other cleanup patches I sent in about a week ago). Bruce got horribly backlogged recently and didn't get any patches in to speak of. Since he's in California this week, I'm going to try to pick up the slack so we can still push out beta5 in the next day or so. However, I don't seem to have anything from you on that date in my inbox; could you send it to me off-list? regards, tom lane Something that Fabien Coelho fixed recently broke tonight. I can no longer compile PL/Java on win32 using pgxs since the directory pgxs/src/include/port/win32/* is missing (again). Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Minor problem with Makefile.shlib
Dear Thomas, Something that Fabien Coelho fixed recently broke tonight. I can no longer compile PL/Java on win32 using pgxs since the directory pgxs/src/include/port/win32/* is missing (again). AFAICS, the patch is in the queue waiting for a review. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Minor problem with Makefile.shlib
Thomas Hallgren wrote: Something that Fabien Coelho fixed recently broke tonight. I can no longer compile PL/Java on win32 using pgxs since the directory pgxs/src/include/port/win32/* is missing (again). And in addition to that, the libpostgresql.a is also missing. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Minor problem with Makefile.shlib
AFAICS, the patch is in the queue waiting for a review. Well, the CVS HEAD did work as if it indeed had been applied until yesterday evening. I'm quite sure of that since I took a new snapshot yesterday and created a brand new installation. PL/Java compiled fine on win32 (aside from the warnings I mentioned at the beginning of this thread). I guess the magic is explained because you installed *over* the previous test install you did to check my patch? So the header files were there from this previous install. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 7.4.5 / 7.4.6 crash (pg_hba.conf issue)
I've run across a bug in pg_hba.conf routines which is repeatable in both 32bit intel on Linux and 64bit AMD on FreeBSD with both 7.4.5 and 7.4.6. It results in the postmaster crashing which is quite annoying when it leaves behind it's children. create a file dev.users within the data directory such as the attached. Edit pg_hba.conf to have a line like: hostdb @dev.users 127.0.0.1255.255.255.255 trust Hup the postmaster,. -- anatoly astrope chris dragos geantap kishore rbt ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor problem with Makefile.shlib
Thomas Hallgren schrieb: I have a minor issue with Makefile.shlib. Compiling with win32 it spits out these warnings (the same is true for Cygwin) Makefile.shlib:327: warning: overriding commands for target `libpljava.a' Makefile.shlib:262: warning: ignoring old commands for target `libpljava.a' As it turns out, the rule to make the lib$(NAME).a actually has commands defined in multiple places when Cygwin or win32 is used. In global scope we find the following at line 260: lib$(NAME).a: $(OBJS) ifdef MK_NO_LORDER $(LINK.static) $@ $^ else $(LINK.static) $@ `$(LORDER) $^ | tsort` endif $(RANLIB) $@ Then, further down and win32 specific on line 325: $(shlib) lib$(NAME).a: $(OBJS) ^ This is wrong. Those static import libs should be called lib$(NAME).dll.a and are a completely different beast than the pure static lib from above. But it will only bite when ever a module wants both, static AND shared libs. ifndef DLL_DEFFILE $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS) $(DLLWRAP) $(LDFLAGS_SL) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def $(OBJS) $(SHLIB_LINK) $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def --output-lib lib$(NAME).a else $(DLLWRAP) $(LDFLAGS_SL) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(DLL_DEFFILE) $(OBJS) $(SHLIB_LINK) $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE) --output-lib lib$(NAME).a endif endif # PORTNAME == win32 As I said, it's is no big issue since it just results in two warnings. -- Man is by nature a political animal. (Aristotle, Politics) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pgEdit public beta for Macintosh and Windows
The first public beta for pgEdit is now available (see product description below). If you would like to participate in the beta program, evaluate the software and send some feedback to me (e.g. criticism, bug reports, feature requests). The first responders will receive a 30 day trial registration key to remove demonstration mode restrictions. A limited number of registration keys will be distributed, so respond soon if you would like to receive a registration key. If you don't respond right away, quality feedback is another way to get a registration key :). Thanks for your help! John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL = pgEdit is a high performance SQL editor and development environment designed specifically for PostgreSQL relational databases. pgEdit features include: * SQL Syntax coloring specifically designed for PostgreSQL PostgreSQL represents function bodies as single quoted strings which most editors render with a single color. pgEdit promotes better usability and correctness by using SQL syntax coloring within the body of function strings. Keyword coloring is based directly on the source code of PostgreSQL. * SQL source code execution without saving the file or switching applications pgEdit can execute the SQL source code for (1) the entire buffer, (2) the highlighted region, (3) the current SQL containing the cursor, or (4) the current SQL line to the end of the file buffer. * Direct integration with psql, the PostgreSQL interactive terminal In addition to SQL, almost all psql commands are supported. This provides a powerful facility for examining, designing, and managing databases. * Extensive and customizable editing facilities pgEdit is a full featured text editor with hundreds of commands available. A friendly interface is included to provide online documentation and customize the key bindings for any command. Menu shortcuts can also be customized. pgEdit supports traditional Macintosh and Windows editing features, as well as Emacs-style key bindings. * Integrated documentation Help in pgEdit is provided with context sensitive links to the online documentation displayed in your preferred web browser. The PostgreSQL documentation is also included with direct links to important sections provided in the pgEditHelp menu. The documentation for the SQL command nearest to the cursor can be retrieved by pressing a user configurable key sequence. * Cross platform and easy to install pgEdit is a native application for both Macintosh and Windows. It does not use Java or require installation of external libraries. You have the option of using the version of psql included with pgEdit or a different version installed anywhere on your hard drive. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] cygwin build failure
Reini Urban [EMAIL PROTECTED] writes: I'm just testing a new build from CVS with atttached patch. Patch applied. src/interfaces/ecpg/preproc: the .y and *.l files need to be touched and the generated .c/.h recompiled. They are outdated, at least on CVS. They don't exist in CVS. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Tired of -Wold-style-definition already
I'd like to propose removing -Wold-style-definition from the default gcc flags. It is cluttering my make logs with warnings that can't be got rid of because they are about code generated by flex. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Tired of -Wold-style-definition already
Tom Lane wrote: I'd like to propose removing -Wold-style-definition from the default gcc flags. It is cluttering my make logs with warnings that can't be got rid of because they are about code generated by flex. Would it not be possible to suppress the warnings just for the flex-generated code? cheers andrew ---(end of broadcast)--- TIP 3: 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: [HACKERS] 7.4.5 / 7.4.6 crash (pg_hba.conf issue)
Rod Taylor [EMAIL PROTECTED] writes:
I've run across a bug in pg_hba.conf routines which is repeatable in
both 32bit intel on Linux and 64bit AMD on FreeBSD with both 7.4.5 and
7.4.6. It results in the postmaster crashing which is quite annoying
when it leaves behind it's children.
Off-by-one memory allocation problem --- it only bites you if the string
lengths are just right, which probably explains the lack of prior
reports even though the bug has been there since 7.3. Simplest fix is
Index: hba.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/hba.c,v
retrieving revision 1.87.2.4
retrieving revision 1.87.2.5
diff -c -r1.87.2.4 -r1.87.2.5
*** hba.c 13 Apr 2003 04:07:31 - 1.87.2.4
--- hba.c 17 Nov 2004 19:54:53 - 1.87.2.5
***
*** 281,287
{
if (strlen(comma_str))
{
! comma_str = repalloc(comma_str,
strlen(comma_str) + 1);
strcat(comma_str, MULTI_VALUE_SEP);
}
comma_str = repalloc(comma_str,
--- 281,287
{
if (strlen(comma_str))
{
! comma_str = repalloc(comma_str,
strlen(comma_str) + 1 + 1);
strcat(comma_str, MULTI_VALUE_SEP);
}
comma_str = repalloc(comma_str,
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Tired of -Wold-style-definition already
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I'd like to propose removing -Wold-style-definition from the default gcc flags. It is cluttering my make logs with warnings that can't be got rid of because they are about code generated by flex. Would it not be possible to suppress the warnings just for the flex-generated code? IMHO it's not worth the trouble. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_resetxlog options
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Why does pg_resetxlog seem top be the only one of our programs that has no long form options (or at least the only one that calls getopt rather than getopt_long)? Should we make it consistent with everything else? I think just laziness on my part when I first wrote it --- it only had one or two options anyway, and didn't seem to need long options. But if converting to getopt_long is the easy way to avoid a porting problem, do it. Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. cheers andrew Index: src/bin/pg_resetxlog/pg_resetxlog.c === RCS file: /home/cvsmirror/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c,v retrieving revision 1.24 diff -c -r1.24 pg_resetxlog.c *** src/bin/pg_resetxlog/pg_resetxlog.c 29 Aug 2004 16:34:48 - 1.24 --- src/bin/pg_resetxlog/pg_resetxlog.c 17 Nov 2004 20:24:43 - *** *** 36,41 --- 36,45 #include sys/time.h #include time.h #include unistd.h + #ifdef HAVE_GETOPT_H + #include getopt.h + #endif + #include access/xlog.h #include access/xlog_internal.h ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] ambiguous column names in subqueries
I have a query where I want to override one of the output column names. The problem is that the columns are coming from a subquery. So I have do something like: select *, coalesce(a,b) as a from subquery The problem is that * still includes column a. And replacing * with a complete list of every column coming from the subquery is a non-starter. That would make maintaining the query a total nightmare. Every change to the subquery would require editing multiple levels of these explicit lists. I thought Postgres already allowed for this by taking only the last column by a given name. At least that's what I had observed in practice. It turns out it wasn't postgres it was the driver that was doing it. Drivers obviously have no way to disambiguate either so apparently they just return the last column by the specified name. The problem is this doesn't help me when I want to use the column in an ORDER BY clause or elsewhere in the query. Is there any help in the SQL spec on this? Some syntax for disambiguating references or removing columns from the output list? Otherwise, I think Postgres should behave differently in this case: For example: slo= select * from (select 1 as foo, 2 as foo); ERROR: subquery in FROM must have an alias HINT: For example, FROM (SELECT ...) [AS] foo. slo= select * from (select 1 as foo, 2 as foo) as x; foo | foo -+- 1 | 2 (1 row) What purpose is there to returning both columns to the outer query? The columns become effectively inaccessible. There's no syntax for disambiguating any reference. I think postgres should treat the second alias as hiding the first. Currently there's no way to selectively override a single output column. The only way to do is to put your query in a subquery and list every single output column again except the one you want to override. Note that I'm not saying Postgres should remove ambiguous columns from different tables for the inner query. Only for subsequent layers where they have no way to access them anyways. -- greg ---(end of broadcast)--- TIP 3: 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: [HACKERS] 7.4.5 / 7.4.6 crash (pg_hba.conf issue)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 17 Nov 2004, Tom Lane wrote: Off-by-one memory allocation problem --- it only bites you if the string lengths are just right, which probably explains the lack of prior reports even though the bug has been there since 7.3. Is this worth new dot releases? Regards, - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBm79Ztl86P3SPfQ4RAh34AKDp/fCXVBYcbY1dYKO/TfwteNnBZACgpnl5 uG/yaUhmh97ZM+h9al1fmeE= =RdZ5 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4.5 / 7.4.6 crash (pg_hba.conf issue)
Devrim GUNDUZ [EMAIL PROTECTED] writes: Off-by-one memory allocation problem --- it only bites you if the string lengths are just right, which probably explains the lack of prior reports even though the bug has been there since 7.3. Is this worth new dot releases? I'd say not. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] split_part bug
PostgreSQL 8.0b4 as released.
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',1);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',2);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',3);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',4);
should return a b c, and d
returns a, null, null, null
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',2);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',3);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',4);
should return b c, and d
returns b, c, null
... John
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] pg_resetxlog options
Andrew Dunstan [EMAIL PROTECTED] writes: Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. The Single Unix Spec says that getopt() is supposed to be defined by unistd.h, but I guess reading the spec closely is not a hobby in Redmond... Patch applied. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ambiguous column names in subqueries
Greg Stark wrote: What purpose is there to returning both columns to the outer query? The columns become effectively inaccessible. There's no syntax for disambiguating any reference. I think postgres should treat the second alias as hiding the first. Currently there's no way to selectively override a single output column. The only way to do is to put your query in a subquery and list every single output column again except the one you want to override. Note that I'm not saying Postgres should remove ambiguous columns from different tables for the inner query. Only for subsequent layers where they have no way to access them anyways. Please don't. JDBC (for example) has no problem with ambiguous columns, you just access them by index, and you have resultset metadata available if you want to implement your own rules for finding those indexes. It sounds like your problem really lies in the API you are using to access the results. -O ---(end of broadcast)--- TIP 3: 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: [HACKERS] ambiguous column names in subqueries
Greg Stark [EMAIL PROTECTED] writes: Is there any help in the SQL spec on this? Rename the columns at the output of the subselect, eg select * from (select 1 as foo, 2 as foo) as x(foo1, foo2); regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Tired of -Wold-style-definition already
On Wed, Nov 17, 2004 at 01:50:00PM -0500, Tom Lane wrote: I'd like to propose removing -Wold-style-definition from the default gcc flags. It is cluttering my make logs with warnings that can't be got rid of because they are about code generated by flex. Oh, so that's what all the noise I see is coming from :-( If there's a vote, I vote aye. -- Alvaro Herrera ([EMAIL PROTECTED]) Jude: I wish humans laid eggs Ringlord: Why would you want humans to lay eggs? Jude: So I can eat them ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] split_part bug
John Hansen [EMAIL PROTECTED] writes:
PostgreSQL 8.0b4 as released.
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',1);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',2);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',3);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',4);
should return a b c, and d
returns a, null, null, null
Works fine for me. What encoding/locale are you using?
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] ambiguous column names in subqueries
Oliver Jowett [EMAIL PROTECTED] writes: Please don't. JDBC (for example) has no problem with ambiguous columns, you just access them by index, and you have resultset metadata available if you want to implement your own rules for finding those indexes. It sounds like your problem really lies in the API you are using to access the results. The API with the problem is the SQL language. It's there that the columns become inaccessible. It seems silly for the language to let you create variables that you can't reference. Yes it's true that you could access them from the result set but that's even worse. You have variables that you can't access from within the language but that can escape to the outside world to cause real effects. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ambiguous column names in subqueries
Tom Lane [EMAIL PROTECTED] writes: select * from (select 1 as foo, 2 as foo) as x(foo1, foo2); How is this different than simply listing all the columns instead of the *? I still have the maintenance problem of having to edit the outer query every time the list of columns from the inner query changes. -- greg ---(end of broadcast)--- TIP 3: 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: [HACKERS] split_part bug
Works fine for me. What encoding/locale are you using? unicode / c ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] split_part bug
John Hansen [EMAIL PROTECTED] writes:
Works fine for me. What encoding/locale are you using?
unicode / c
[ shrug... ] Works fine for me in unicode, too.
u=# select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y z','
',1);
split_part
a
(1 row)
u=# select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y z','
',2);
split_part
b
(1 row)
u=# select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y z','
',3);
split_part
c
(1 row)
u=# select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y z','
',4);
split_part
d
(1 row)
regards, tom lane
---(end of broadcast)---
TIP 3: 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: [HACKERS] ambiguous column names in subqueries
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: select * from (select 1 as foo, 2 as foo) as x(foo1, foo2); I still have the maintenance problem of having to edit the outer query every time the list of columns from the inner query changes. Yeah, but at least you only have to do it in one place. AFAICS removing columns from the inner query because they have duplicate names would violate the SQL spec, so it's not going to happen. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] split_part bug
[ shrug... ] Works fine for me in unicode, too. never mind me,. I broke it. seems my assumption that UCS2 == UTF16 was way off ... john ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_resetxlog options
Andrew Dunstan wrote: Some other time maybe. Meanwhile, this patch ought to make it compile more cleanly on Windows - not sure why I get errors there but not Linux. Because getopt() is normally declared in unistd.h, not getopt.h (Windows being an exception?). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Tired of -Wold-style-definition already
On Wed, 2004-11-17 at 14:59 -0500, Tom Lane wrote: Would it not be possible to suppress the warnings just for the flex-generated code? IMHO it's not worth the trouble. I think this is the better course. At least here, flex-generated files produce warnings even without -Wold-style-definition: % gcc -O2 -Wall -Wmissing-prototypes -fno-strict-aliasing -g -I. -I../../../src/include -D_GNU_SOURCE -c -o gram.o gram.c -MMD In file included from gram.y:8445: scan.c:6065: warning: no previous prototype for 'base_yyget_lineno' scan.c:6074: warning: no previous prototype for 'base_yyget_in' scan.c:6082: warning: no previous prototype for 'base_yyget_out' scan.c:6090: warning: no previous prototype for 'base_yyget_leng' scan.c:6099: warning: no previous prototype for 'base_yyget_text' scan.c:6108: warning: no previous prototype for 'base_yyset_lineno' scan.c:6120: warning: no previous prototype for 'base_yyset_in' scan.c:6125: warning: no previous prototype for 'base_yyset_out' scan.c:6130: warning: no previous prototype for 'base_yyget_debug' scan.c:6135: warning: no previous prototype for 'base_yyset_debug' scan.c:6141: warning: no previous prototype for 'base_yylex_destroy' % flex --version flex 2.5.31 % gcc --version gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-3) [...] -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Tired of -Wold-style-definition already
Neil Conway [EMAIL PROTECTED] writes: I think this is the better course. At least here, flex-generated files produce warnings even without -Wold-style-definition: That's because you're using a badly broken flex: % flex --version flex 2.5.31 I'd recommend reverting to 2.5.4. IIRC we have found worse problems than just warnings with 2.5.31. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Tired of -Wold-style-definition already
On Wed, 2004-11-17 at 20:22 -0500, Tom Lane wrote: That's because you're using a badly broken flex Sure, but my point is just that different versions of flex, in general, will provoke different compiler warnings. I don't see that it is a net win to disable a flag across the _whole_ source tree just because it complains about the code generated by a particular version of flex. Why not just disable warnings for just the flex-generated files? IIRC we have found worse problems than just warnings with 2.5.31. Do you think these problems are sufficiently bad that we need to declare 2.5.31 unsupported? -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] are there any cons to linking libstdc++ with postgresql?
Hi! I'm not a linking guru... Is there a penalty for setting LDFLAGS+= -lstdc++ when building postgresql? Postgis includes a bunch of useful functions for manipulating spatial data. Some of them are provided by geos, a separate c++ library, with postgis providing wrappers. According to postgis docs, postgresql _must_ be configured with LDFLAGS containing -lstdc++ for this to work. I can confirm this. The postgis port provides the WITH_GEOS tunable, but it has no effect unless the above adjustment is made to postgresql. The port makes no mention of this. Is there a penalty in just leaving LDFLAGS+= -lstdc++ in the postgresql port Makefile? Bad idea? What do you think? /Palle ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Tired of -Wold-style-definition already
Tom Lane wrote: That's because you're using a badly broken flex: % flex --version flex 2.5.31 I know very little (enough to get by) about the configuration phase when building postgresql but couldn't this be checked for? That is, configure could check the version of various tools, like flex, and warn if appropriate. K. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Tired of -Wold-style-definition already
Kevin HaleBoyes [EMAIL PROTECTED] writes: Tom Lane wrote: That's because you're using a badly broken flex: % flex --version flex 2.5.31 That is, configure could check the version of various tools, like flex, and warn if appropriate. It does, although I find that the warnings are of little use since people tend not to read every line of configure's output. (We can't make it error out, only warn, because you aren't necessarily going to use the installed flex anyway...) regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Tired of -Wold-style-definition already
Neil Conway [EMAIL PROTECTED] writes: Why not just disable warnings for just the flex-generated files? Because it's a pain in the neck to do so; it'll require klugery in half a dozen different Makefiles. (I don't see any easy way to make the change apply only to the flex files, and not to the other .c files in the same subdirectories, either.) If I thought the old-style-definition warning was actually useful, then I'd be up for that, but I don't find it worth the trouble. We can run a build every so often with it turned on just to see if any old-style defs have snuck in, but we don't need to have it on as a regular thing. IMHO anyway. IIRC we have found worse problems than just warnings with 2.5.31. Do you think these problems are sufficiently bad that we need to declare 2.5.31 unsupported? We have. You'll notice that releases are still made with 2.5.4. You can probably find something about this in the archives. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] are there any cons to linking libstdc++ with postgresql?
Palle Girgensohn [EMAIL PROTECTED] writes: Is there a penalty in just leaving LDFLAGS+= -lstdc++ in the postgresql port Makefile? Bad idea? Yup. The portability hazards are considerable. I'm a bit surprised the postgis guys seem to think it works. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] are there any cons to linking libstdc++ with
Does the same arguments apply for linking with libc_r (pthreads)? It is needed by plpython, at least on FreeBSD 4.10 (probably all versions). /Palle --On onsdag, november 17, 2004 20.49.20 -0500 Tom Lane [EMAIL PROTECTED] wrote: Palle Girgensohn [EMAIL PROTECTED] writes: Is there a penalty in just leaving LDFLAGS+= -lstdc++ in the postgresql port Makefile? Bad idea? Yup. The portability hazards are considerable. I'm a bit surprised the postgis guys seem to think it works. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Tired of -Wold-style-definition already
On Wed, 2004-11-17 at 20:44 -0500, Tom Lane wrote: It does, although I find that the warnings are of little use since people tend not to read every line of configure's output. AFAICS no such warning is emitted. Perhaps you are thinking of the warnings about using the wrong version of bison, or the warning we emit for flex 2.5.3? -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ambiguous column names in subqueries
Tom Lane [EMAIL PROTECTED] writes: AFAICS removing columns from the inner query because they have duplicate names would violate the SQL spec, so it's not going to happen. That's really what I was asking I guess. Does the spec require the current behaviour. An alternative would be some way to explicitly remove columns from a result set. Something like SELECT a+1 AS a, b+1 AS b, * EXCEPT (a,b) FROM (SELECT 1 AS a, 2 as b, 3 as c) -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
