Re: [BUGS] BUG #2424: initdb Did Not Escape the Password
Yes, I was going to rework the patch to use the ideas you suggested. I wasn't going to apply it as-is. Anyway, feel free to address it. --- Tom Lane wrote: > Bruce Momjian writes: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > I don't particularly like this patch, because it is predicated on a > false assumption, namely that initdb uses libpq to talk to the backend. > ISTM PQescapeString is not the thing to use. (As a concrete example > of why not, there'll be no way to make it use the correct value of > standard_conforming_strings, when that default changes.) > > I think the best solution is probably to use the existing escape_quotes > function and to place its output in an E'' string. > > I looked through initdb to see if there were any other places where it > was creating SQL string literals that might have escaping problems. > All of the COPY commands it issues are potentially at risk: consider > the possibility that the installation sharedir has a quote or backslash > in its path. I didn't see any other holes though. > > Will fix this later today. > > regards, tom lane > -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Strange random() Correlation
On May 27 11:50, Tom Lane wrote: > Volkan YAZICI <[EMAIL PROTECTED]> writes: > > ISTM, there's a problem in the correlation of random() to outer JOINs. > > The random() functions are being evaluated more than once because the > subselect gets "flattened" into the outer query, so that you have > the equivalent of > > select random(), ... where t2.id = random() ... Oops, sorry. I've just remembered this. > We've previously discussed preventing the planner from flattening if > there are any volatile functions in the sub-select's output list, but > I think that would probably do about as much harm as good. It can be quite informative to learn the pros and cons of this issue, but I couldn't find related discussion in archives. I'd be so appreciated if you can remember its subject or anything specifier for the thread. > > Furthermore, if you'd append an "OFFSET 0" to subselect, output becomes > > more stable but still has some inconsistencies. > > I didn't see any... That's all caused by a mis-interpretation of the output by me. Replacing "(random() * 100)::int % 17" with "1 + ((random() * 100)::int % 16)" solved my above question. Regards. ---(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 #2424: initdb Did Not Escape the Password
Bruce Momjian writes: > Your patch has been added to the PostgreSQL unapplied patches list at: I don't particularly like this patch, because it is predicated on a false assumption, namely that initdb uses libpq to talk to the backend. ISTM PQescapeString is not the thing to use. (As a concrete example of why not, there'll be no way to make it use the correct value of standard_conforming_strings, when that default changes.) I think the best solution is probably to use the existing escape_quotes function and to place its output in an E'' string. I looked through initdb to see if there were any other places where it was creating SQL string literals that might have escaping problems. All of the COPY commands it issues are potentially at risk: consider the possibility that the installation sharedir has a quote or backslash in its path. I didn't see any other holes though. Will fix this later today. regards, tom lane ---(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] Strange random() Correlation
Volkan YAZICI <[EMAIL PROTECTED]> writes: > ISTM, there's a problem in the correlation of random() to outer JOINs. The random() functions are being evaluated more than once because the subselect gets "flattened" into the outer query, so that you have the equivalent of select random(), ... where t2.id = random() ... We've previously discussed preventing the planner from flattening if there are any volatile functions in the sub-select's output list, but I think that would probably do about as much harm as good. The cases where this actually matters are rare and the programmer knows darn well what he's doing, so the workaround of inserting an OFFSET 0 to prevent the flattening seems acceptable to me. > Furthermore, if you'd append an "OFFSET 0" to subselect, output becomes > more stable but still has some inconsistencies. I didn't see any... regards, tom lane ---(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 #2458: Postgresql crash
My application does not use any transactions (other than the implicit per statement ones that must exist), but I think I did edit some functions in pgadmin around that time so it may be that bug or something similar/related. I didn't bother to upgrade to 8.1.4 because I thought it was just a security fix that didn't apply to me. I'll upgrade tonight during off hours. - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Cstdenis" <[EMAIL PROTECTED]> Cc: Sent: Friday, May 26, 2006 8:05 PM Subject: Re: [BUGS] BUG #2458: Postgresql crash > "Cstdenis" <[EMAIL PROTECTED]> writes: > > [ SIGSEGV in plpgsql_xact_cb ] > > I think this is probably an instance of the bug patched here: > http://archives.postgresql.org/pgsql-committers/2006-03/msg00022.php > > If you're certain that your applications never redefine a plpgsql > function that might be in active use, then we might need to look > harder. Otherwise, please update to 8.1.4 and see if the problem > recurs ... > > regards, tom lane > ---(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 #2456: How to write user defined functions in Postgress sql
Vivekananda wrote: > I have good knowledge in Oracle-Pl/sql.But,now my client wants to use > PGSQL.Now i am sending function as below. > This is *not* a bug. Consider posting in the correct list pgsql-general. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(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
[BUGS] Strange random() Correlation
Hi, ISTM, there's a problem in the correlation of random() to outer JOINs. Here's a test case: BEGIN; CREATE TEMP TABLE nuc_codes (id serial, code char(1)); COPY nuc_codes (code) FROM stdin; A C D G H K M N R S T U V W X Y \. SELECT id, code FROM nuc_codes; SELECT T1.r1, T1.r2, T2.code, T3.code FROM (SELECT ((random() * 100)::int4 % 17), ((random() * 100)::int4 % 17) FROM generate_series(1, 10) ) AS T1 (r1, r2) LEFT OUTER JOIN nuc_codes T2 ON (T2.id = T1.r1) LEFT OUTER JOIN nuc_codes T3 ON (T3.id = T1.r2); ROLLBACK; If you run above query, you'll realize the inconsistency in the output. Furthermore, if you'd append an "OFFSET 0" to subselect, output becomes more stable but still has some inconsistencies. Regards. P.S. Query tested on 8.1.4 and a 2-3 weeks old cvs tip. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
