Re: [BUGS] "strange" rule behavior with nextval on new.* fields

2004-11-11 Thread Fabien COELHO
I'd like to report the following "strange" behavior that I encountered while trying (a bad idea, I know) to use a rule as a "poor man sql-trigger". I noticed that I forget about the bug report guidelines... The above mentionned strange behavior is with a recent cvs tree, between beta3 and beta4,

Re: [BUGS] BUG #1315: unconvertible BIG5 character 0xf9d8

2004-11-11 Thread Tatsuo Ishii
> The following bug has been logged online: > > Bug reference: 1315 > Logged by: CN > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.0 Beta > > Operating system: Linux > > Description:unconvertible BIG5 character 0xf9d8 > > Details: > > Sorry for c

[BUGS] BUG #1315: unconvertible BIG5 character 0xf9d8

2004-11-11 Thread PostgreSQL Bugs List
The following bug has been logged online: Bug reference: 1315 Logged by: CN Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Linux Description:unconvertible BIG5 character 0xf9d8 Details: Sorry for cross posting here after 2 days'

Re: [BUGS] BUG #1314: STATEMENT_TIMEOUT DOES NOT WORK PROPERLY

2004-11-11 Thread Tom Lane
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > CREATE OR REPLACE FUNCTION fn_test() > RETURNS "varchar" AS > $BODY$ > DECLARE >c refcursor; >r record; > BEGIN >SET SESSION STATEMENT_TIMEOUT = 1000; >OPEN C FOR SELECT * FROM T_KULLANICILAR FOR UPDATE; >FETCH C INTO R; >

[BUGS] BUG #1314: STATEMENT_TIMEOUT DOES NOT WORK PROPERLY

2004-11-11 Thread PostgreSQL Bugs List
The following bug has been logged online: Bug reference: 1314 Logged by: Adnan DURSUN Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: W2K Description:STATEMENT_TIMEOUT DOES NOT WORK PROPERLY Details: Hi, i use PostgreSQL 8 Beta4.

Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly

2004-11-11 Thread Josh Berkus
Andrea, > i'm sorry for the curiosity but > could you share, if it's possible, this workaround? ;) > (if it's not the one you describe at the beginning thread > e.g. don't use LIMIT 1) Well, we actually roped in the pg_locks view to do a "SELECT the first row not already locked for update"

[BUGS] BUG #1313: problems with array syntax parsing in SQL statements

2004-11-11 Thread PostgreSQL Bugs List
The following bug has been logged online: Bug reference: 1313 Logged by: Pascal Pochet Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.5 Operating system: Mac OS X Description:problems with array syntax parsing in SQL statements Details: In INSERT sta

Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly

2004-11-11 Thread Bruce Momjian
Josh Berkus wrote: > Tom, Neil, > > > > Au contraire: every row that gets locked will be returned to the client. > > > The gripe at hand is that the number of such rows may be smaller than > > > the client wished, because the LIMIT step is applied before we do the > > > FOR UPDATE step > > As I s

Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly

2004-11-11 Thread Josh Berkus
Bruce, Ah, yes, which reminds me I need to generate that doc patch. > I am wondering if a documentation warning about the use of FOR UPDATE > and LIMIT is a good idea. If we can't be sure the LIMIT will return a > guaranteed number of rows, should we just disallow that combination? I > realize

Re: [BUGS] BUG #1312: the ordinal 2821 could not be located

2004-11-11 Thread Magnus Hagander
> The following bug has been logged online: > > Bug reference: 1312 > Logged by: Amie > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.0 Beta > > Operating system: windows 2000 prof > > Description:the ordinal 2821 could not be located > > Details: