Re: [HACKERS] [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: That's not fixing the problem, unless your proposal includes never issuing any warnings at all, for anything. No warning for * because it is intentional, but warning for actual stop words. No, you're focusing on one symptom not the problem. The problem is that we've got user-visible behavior going on during what's effectively a chance event, ie, a cache reload. One possible real solution would be to tweak the dictionary APIs so that the dictionaries can find out whether this is the first load during a session, or a reload, and emit notices only in the first case. Yea, that would work too. Or just throw an error for a stop word in the file and then you never get a reload (use * instead). -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: One possible real solution would be to tweak the dictionary APIs so that the dictionaries can find out whether this is the first load during a session, or a reload, and emit notices only in the first case. Yea, that would work too. Or just throw an error for a stop word in the file and then you never get a reload (use * instead). Hm, that's a thought --- it'd be a way to solve the problem without an API change for dictionaries, which is something to avoid at this late stage of the 8.3 cycle. Come to think of it, does the ts_cache stuff work properly when an error is thrown in dictionary load (ie, is the cache entry left in a sane state)? 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: [HACKERS] [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: That's not fixing the problem, unless your proposal includes never issuing any warnings at all, for anything. No warning for * because it is intentional, but warning for actual stop words. No, you're focusing on one symptom not the problem. The problem is that we've got user-visible behavior going on during what's effectively a chance event, ie, a cache reload. One possible real solution would be to tweak the dictionary APIs so that the dictionaries can find out whether this is the first load during a session, or a reload, and emit notices only in the first case. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice
Bruce Momjian [EMAIL PROTECTED] writes: I just talked to Teodor and we discussed this problem. My idea is to have a special marker in the synonym table, perhaps * to indicate the presence of _any_ stop word at that location. This will not produce any warnings because it is clearly intentional. That's not fixing the problem, unless your proposal includes never issuing any warnings at all, for anything. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I just talked to Teodor and we discussed this problem. My idea is to have a special marker in the synonym table, perhaps * to indicate the presence of _any_ stop word at that location. This will not produce any warnings because it is clearly intentional. That's not fixing the problem, unless your proposal includes never issuing any warnings at all, for anything. No warning for * because it is intentional, but warning for actual stop words. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
