Re: [BUGS] INSERT/SELECT with ORDER BY
Stephan Szabo writes: > > Unless I'm horribly misreading the spec, this is correct. > ORDER BY is used in reference to cursor definitions and > direct select statements, but is not part of query expressions > which is what the INSERT INTO references. > > ::= > INSERT INTO > > > ::= > [] > > | DEFAULT VALUES > > ::= > > But, this may be a useful extension to allow, at least with the > existance of LIMIT. > > Stephan Szabo > [EMAIL PROTECTED] > > On Thu, 17 Aug 2000, Bob Rivoir wrote: > > > > Please enter a FULL description of your problem: > > > > I got the following error message when I tried to do an INSERT using > > SELECT ... ORDER BY: > > > > ERROR: ORDER BY is not allowed in INSERT/SELECT Is 7.1 able to do INSERT/SELECT with ORDER BY and LIMIT ? Dirk ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Please, fix!!! The backend can crash on your system!
If PostgreSQL failed to compile on your computer or you found a bug that is likely to be specific to one platform then please fill out this form and e-mail it to [EMAIL PROTECTED] To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] If you not only found the problem but solved it and generated a patch then e-mail it to [EMAIL PROTECTED] instead. Please use the command "diff -c" to generate the patch. You may also enter a bug report at http://www.postgresql.org/ instead of e-mail-ing this form. POSTGRESQL BUG REPORT TEMPLATE Your name : Alexis Wilke Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : trust me, doesn't matter Operating System (example: Linux 2.0.26 ELF) : trust me, doesn't matter PostgreSQL version (example: PostgreSQL-7.0): since PostgreSQL-6.5.x and still in the code Compiler used (example: gcc 2.8.0) : trust me, doesn't matter Please enter a FULL description of your problem: It crashes when pg_database is too large. This is because the index is compare to max with <= instead of <. I already fixed the bug on my system. That's at line Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- Create many database (or create/destroy the same many times). Once the pg_database is more than one page (is 16Kb or more) then it starts crashing. (may not crash on all systems, but trust me, my fix will work GREAT). If you know how this problem might be fixed, list the solution below: - Okay, so go in the following file: ./src/backend/utils/misc/database.c and move to the line #183 (V7.0.1) There, fix the for() as is: for(i = 0; i < max; i++) Why? Well, because 'i' starts at 0, therefore, you can't access the tuple number 'max'. If you look in other source files, you will quickly see that all these for() loops are starting with an index of 1 and use some special functions/macros to access the tuple data. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Please, fix!!! The backend can crash on your system!
In the current sources, I see: for (lineoff = FirstOffsetNumber; lineoff <= max; lineoff++) so it looks like we have this fixed. You can check the 7.1RC1. > > If PostgreSQL failed to compile on your computer or you found a bug that > is likely to be specific to one platform then please fill out this form > and e-mail it to [EMAIL PROTECTED] > > To report any other bug, fill out the form below and e-mail it to > [EMAIL PROTECTED] > > If you not only found the problem but solved it and generated a patch > then e-mail it to [EMAIL PROTECTED] instead. Please use the > command "diff -c" to generate the patch. > > You may also enter a bug report at http://www.postgresql.org/ instead of > e-mail-ing this form. > > > POSTGRESQL BUG REPORT TEMPLATE > > > > Your name : Alexis Wilke > Your email address: [EMAIL PROTECTED] > > > System Configuration > - > Architecture (example: Intel Pentium) : trust me, doesn't matter > > Operating System (example: Linux 2.0.26 ELF): trust me, doesn't matter > > PostgreSQL version (example: PostgreSQL-7.0): since PostgreSQL-6.5.x > and still in the code > > Compiler used (example: gcc 2.8.0) : trust me, doesn't matter > > > Please enter a FULL description of your problem: > > > It crashes when pg_database is too large. This is because > the index is compare to max with <= instead of <. I already > fixed the bug on my system. That's at line > > > > Please describe a way to repeat the problem. Please try to provide a > concise reproducible example, if at all possible: > -- > > Create many database (or create/destroy the same many times). > > Once the pg_database is more than one page (is 16Kb or more) then it > starts > crashing. (may not crash on all systems, but trust me, my fix > will work GREAT). > > > > If you know how this problem might be fixed, list the solution below: > - > > Okay, so go in the following file: > > ./src/backend/utils/misc/database.c > > and move to the line #183 (V7.0.1) > > There, fix the for() as is: > > for(i = 0; i < max; i++) > > Why? Well, because 'i' starts at 0, therefore, you > can't access the tuple number 'max'. If you look in > other source files, you will quickly see that all > these for() loops are starting with an index of > 1 and use some special functions/macros to access > the tuple data. > > > > > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/?.refer=text > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] Problem with character results
I have a table with a char(20) column called 'name'. This SELECT returns the proper records: SELECT * FROM table WHERE name = 'John'; But this one does not return the same records: SELECT * FROM table WHERE UPPER(name) = 'JOHN'; I believe this is contrary to the SQL standard, which (as I understand it) says that a scalar function applied to a single character field argument should return a value of the same data type as its argument. The second SELECT seems to be returning a VARCHAR(20) result which includes the 16 trailing spaces. And those spaces are significant for the equality test. If the string literal in the second SELECT has 16 trailing spaces added, the correct records are returned. Am I right that this is non-standard behavior? Is this a known problem? What is its status in releases after 7.0.2? BTW, the standard calls for CHARACTER SET and COLLATION support, which include specifying if PAD characters are inserted to make the shorter comparand as long as the longer one before the comparison is performed. One might say that PG behaves as though PAD were turned off. But I think that misses the root of this problem, which is that UPPER and other functions return the wrong result type here. Thanks Jim Ballard
[BUGS] date_part bug
Hello:
I'm using postgres 7.0.2. When I use date_part('day', date) sometimes I
get wrong values. Ie:
and date_part('day', '1999-3-28')=27
and date_part('day', '2000-3-26')=25
Is it a bug?
--
Salvador Mainé
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Re: date_part bug
> I'm using postgres 7.0.2. When I use date_part('day', date) sometimes I
> get wrong values. Ie:
> and date_part('day', '1999-3-28')=27
> and date_part('day', '2000-3-26')=25
> Is it a bug?
It is a problem evaluating day numbers around daylight savings time
transitions. Fixed (I believe) in the upcoming 7.1 release.
- Thomas
---(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
[BUGS] Re: [PATCHES] Error in the date field (with NULL value...).Thanks!
> How can I "binds" PostgreSQL to consider '' as null ?
You can modify src/backend/utils/{datetime,date,timestamp}.c to accept
an empty string as a null value. But imho it is better to fix this in
your input file, perhaps using sed:
sed "s/''/NULL/g" < informix.dump > pg.dump
- Thomas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
