[BUGS] BUG #8365: Two documentation suggestions
The following bug has been logged on the website: Bug reference: 8365 Logged by: David Tonhofer Email address: bugh...@gluino.name PostgreSQL version: 9.2.4 Operating system: Linux Description: Suggestions for documentation: http://www.postgresql.org/docs/9.2/static/auth-pg-hba-conf.html; - Quoting one of the keywords in a database, user, or address field (e.g., all or replication) makes the word lose its special character, - Replace character by meaning for clarity. - Require the client to supply an MD5-encrypted password for authentication. - Replace encrypted by hashed (as done in http://www.postgresql.org/docs/9.2/static/auth-methods.html#AUTH-PASSWORD ). - Actually this should be Require the client to supply an MD5 hash based on a password for authentication. ...as the exchange is more complex than just supplying a hash. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8366: getClob() stopped working from which version?
The following bug has been logged on the website: Bug reference: 8366 Logged by: developer Email address: vaishu.sweet...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: windows Description: I have a table with TEXT column in it.. When I used version 8.3.21 previously, getClob() worked to retrieve the column's data.. but now its not working.. getString() is working and I am using that to retrieve the value. I want to provide a check inorder to use the right statement. So please tell me what that check should be? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8367: wrong example in 8.17.10
The following bug has been logged on the website: Bug reference: 8367 Logged by: KOIZUMI Satoru Email address: koizumi...@minos.ocn.ne.jp PostgreSQL version: 9.2.4 Operating system: MacOSX Description: In 8.17.10 Constraints on Ranges of PostgreSQL 9.2.4 Documentation, a constraint will prevent the overlapping values in an example. But in the example, range [2010-01-01 11:30, 2010-01-01 13:00) and range [2010-01-01 14:45, 2010-01-01 15:45) do not overlap. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8367: wrong example in 8.17.10
koizumi...@minos.ocn.ne.jp writes: In 8.17.10 Constraints on Ranges of PostgreSQL 9.2.4 Documentation, a constraint will prevent the overlapping values in an example. But in the example, range [2010-01-01 11:30, 2010-01-01 13:00) and range [2010-01-01 14:45, 2010-01-01 15:45) do not overlap. No, but the second one overlaps with the range value shown in 8.17.2. So this is correct if it's understood as a continuation of that example. Still, it's kind of a long way from 8.17.2 to 8.17.10. It might be better if this section were recast to use a standalone example --- Jeff, what do you think? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] with recursive ignores side effects?
I have an unexpected issue with a side effects on a table which is ignored
by a recursive query. I've tried to simplify the issue to a simple
example, see the attached sql script.
Version 1 results in:
it / fid / stuff / foo full contents
0 | 0 | | {1:one,2:two}
1 | 1 | one | {1:one,2:*}
2 | 2 | two | {1:*,2:*}
The key issue for me is that table Foo is updated (as shown by the last
column), but although 'two' was updated to '*' by iteration 1, the last
iteration still sees the initial 'two' which does not exist anymore.
Version 2 illustrates more or less the behavior I would have expected.
I've read again Section 7.8 about WITH queries, but I have not seen
anything that would disprove my expectation.
Am I wrong somewhere? Or is this a subtle bug?
--
Fabien.
test.sql
Description: application/sql
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] with recursive ignores side effects?
Fabien COELHO-3 wrote The key issue for me is that table Foo is updated (as shown by the last column), but although 'two' was updated to '*' by iteration 1, the last iteration still sees the initial 'two' which does not exist anymore. Am I wrong somewhere? Or is this a subtle bug? My recollection is that a single statement, including its WITH clauses, always sees whatever database state was in effect at the beginning of the statement's execution. Updates to the database during the statement are not visible until the statement has completed. Note that with the introduction of updateable CTE the use of the RETURNING clause is needed to allow other portions of the same query to see the changes made by the DDL statement. Read section 7.8.2 in detail as you are basically implementing this when you perform data update statements inside a function called using SELECT. I'm not sure I can explain this any better, nor am I certain the documentation is as clear as it could be, but I am pretty certain the behavior itself is intended. A statement is not a procedure but a declaration of what you need to have done. Recursion (iteration) allows you to more easily handle/walk hierarchical data but said hierarchy remains static for the duration of the query. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/with-recursive-ignores-side-effects-tp5766555p5766565.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8366: getClob() stopped working from which version?
vaishu.sweet...@gmail.com vaishu.sweet...@gmail.com wrote: I have a table with TEXT column in it.. When I used version 8.3.21 previously, getClob() worked to retrieve the column's data.. but now its not working.. getString() is working and I am using that to retrieve the value. Please give the exact version of both PostgreSQL and the JDBC driver jar used when you saw a problem. If you can create a short, self-contained test case, that would help. With so little data this can only be a guess, but I'm guessing you may not have updated your JDBC driver jar to a version new enough to understand all the new options for data formatting on the newer PostgreSQL version. This link may be helpful: http://jdbc.postgresql.org/download.html#current If using the latest driver doesn't solve the problem, try setting this property on connection: binaryTransfer=false This is supposed to make things faster, but all the bugs might not be out of it yet. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
