[BUGS] BUG #8467: Slightly confusing pgcrypto example in docs
The following bug has been logged on the website:
Bug reference: 8467
Logged by: Richard Neill
Email address: postgre...@richardneill.org
PostgreSQL version: 9.3.0
Operating system: Documentation bug
Description:
The documentation for pgcrypto:
http://www.postgresql.org/docs/current/static/pgcrypto.html
(and indeed all versions from 8.3-9.3)
contains the following:
Example of authentication:
SELECT pswhash = crypt('entered password', pswhash) FROM ... ;
This returns true if the entered password is correct.
I found this confusing, because it's using the same name, pswhash in 2
places, one of which is a boolean. It would be, imho, clearer to write the
example query as:
SELECT is_authenticated = crypt('entered password', pswhash) FROM ... ;
[Also, should the default example perhaps use gen_salt('bf'), as opposed to
gen_salt('md5') ?]
--
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 #8468: Create index on type tstzrange fail
The following bug has been logged on the website:
Bug reference: 8468
Logged by: marian
Email address: marian.kruc...@gmail.com
PostgreSQL version: 9.3.0
Operating system: Linux
Description:
CREATE INDEX ON tstzrange fail on 9.3.0 and 9.2.4 - default postgres
configuration.
It ate whole memory and was killed by oom.
Example:
postgres=# CREATE TABLE range_test AS SELECT tstzrange(t, t+'1min') tr FROM
generate_series('2000-1-1'::TIMESTAMPTZ, '2010-1-1'::TIMESTAMPTZ, '1min') AS
t1(t);
SELECT 5260321
postgres=# CREATE INDEX ON range_test(tr);
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
The connection to the server was lost. Attempting reset: Failed.
--
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 #8467: Slightly confusing pgcrypto example in docs
On Tue, Sep 24, 2013 at 1:11 AM, postgre...@richardneill.org wrote:
The following bug has been logged on the website:
Bug reference: 8467
Logged by: Richard Neill
Email address: postgre...@richardneill.org
PostgreSQL version: 9.3.0
Operating system: Documentation bug
Description:
The documentation for pgcrypto:
http://www.postgresql.org/docs/current/static/pgcrypto.html
(and indeed all versions from 8.3-9.3)
contains the following:
Example of authentication:
SELECT pswhash = crypt('entered password', pswhash) FROM ... ;
This returns true if the entered password is correct.
I found this confusing, because it's using the same name, pswhash in 2
places, one of which is a boolean. It would be, imho, clearer to write the
example query as:
SELECT is_authenticated = crypt('entered password', pswhash) FROM ... ;
That would render the example incorrect. crypt(pwd, hash) returns the
hash. Not a boolean. This hash needs to be compared to the stored one,
as is explained in the instructions above the example. It's the whole
expression, including the pswhash = that returns boolean.
[Also, should the default example perhaps use gen_salt('bf'), as opposed to
gen_salt('md5') ?]
This, however, might be a good idea. People should of course always
read the documentation, but having the examples including the best
practice would probably be a good idea.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
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 #8469: Xpath behaviour unintuitive / arguably wrong
The following bug has been logged on the website:
Bug reference: 8469
Logged by: Dennis
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: 9.3.0
Operating system: FreeBSD 9.2-RC4
Description:
Hi,
After upgrading an 8.1 version to 9.3.0 I am suddenly seeing text fields
containing amp; where they are populated from XML. This may be a
coincidence and the problem may have existed earlier, in any case, now I
noticed.
I extract the text content of XML nodes using xpath, from something like:
nameJones amp; Smith/name
The reason I end up with amp; is the IMHO rather odd xpath behaviour:
# select xpath('/a/text()', (select xmlelement(name a, 'A B')));
xpath
---
{A amp; B}
The canonical contents of a is A B. At first search I've found some
rather heated debates about this with bits of name calling; I certainly do
not want to get into that and I apologize in advance to those who feel very
strongly about this.
I've seen one fix describe the problem as:
DESCRIPTION: Submitter invokes following statement:
SELECT (XPATH('/*/text()', 'rootlt;/root'))[1].
He expect (escaped) result lt;, but gets
With respect, this bug makes no sense as this produces in fact the right
result. The actual value of root is , it's just escaped when serialized
to XML. If root were to actually contain lt;, it'd be serialized as
amp;lt;. It should not be possible to be blindly cast to a text type, but
explicitly serialized as such.
At least the reviewer at:
http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu
agrees, but I don't know what happened with that.
The python lxml implementation based on libxml2 seems to also agree:
from lxml import etree
a = etree.XML(a/)
a.text = A B;
a
Element a at 8019eb470
etree.tostring(a);
'aA amp; B/a'
a.text
'A B'
a.xpath('/a')
[Element a at 8019eb470]
a.xpath('/a/text()')
['A B']
and similarly for a simple test using xsltproc when set to output text.
If this really is the intended behaviour or something which can or will not
be changed, then it invites double (un)escaping bugs and so on, and I would
like to ask how you are supposed to sanely extract the intended text from a
node in an XML document without risking double (un)escaping, and whether
everybody else is doing it wrong?
I get that xpath(..text()) apparently wants to return a type XML, that this
is on purpose and that there are certain use cases where you want to treat
the result as a type XML which you could not do if it returned an unescaped
text value, like here:
select xmlelement(name b, (select (select xpath('/a/text()', (select
xmlelement(name a, 'A B'[1]));
xmlelement
--
bA amp; B/b
which does not double escape the contents, but where if you cast, it does:
select xmlelement(name b, (select (select xpath('/a/text()', (select
xmlelement(name a, 'A B'[1]::text));
xmlelement
--
bA amp;amp; B/b
(1 row)
I personally don't believe this is very helpful. The escaping is only a
serialization artifact, a text node does not actually contain any amp;s and
so on.
My first thought is then that casting between text and xml should not even
be possible, and always an explicit (de)serialization to/from text using a
chosen encoding (with a shortcut to a PostgreSQL unicode text type), i.e.
treated similarly to the difference between a unicode string and utf-8
encoded representation , and not the equivalent of blindly casting a byte
sequence to a string and back and hoping for the best.
If xpath(..text()) then absolutely has to return a type XML I would be happy
to explicitly serialize it to a type text, if PostgreSQL would forbid me
from (accidentally) storing a result in my text field I almost certainly did
not intend (the escaped value containing amp;). Of course my first
preference would be that it would return a type TEXT.
I appreciate any thoughts and workarounds. I don't really want to add xml
unescapes everywhere, that feels like that php method of unescaping a string
until it stops changing. If the user did intend the literal text amp; I
of course want to preserve that.
Many thanks!
--
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 #8467: Slightly confusing pgcrypto example in docs
Dear Magnus,
Thanks for your reply.
On 24/09/13 18:31, Magnus Hagander wrote:
The following bug has been logged on the website:
Bug reference: 8467
The documentation for pgcrypto:
http://www.postgresql.org/docs/current/static/pgcrypto.html
(and indeed all versions from 8.3-9.3)
contains the following:
---[ ONE] -
Example of authentication:
SELECT pswhash = crypt('entered password', pswhash) FROM ... ;
This returns true if the entered password is correct.
I found this confusing, because it's using the same name, pswhash in 2
places, one of which is a boolean. It would be, imho, clearer to write the
example query as:
[ TWO ]
SELECT is_authenticated = crypt('entered password', pswhash) FROM ... ;
That would render the example incorrect. crypt(pwd, hash) returns the
hash. Not a boolean. This hash needs to be compared to the stored one,
as is explained in the instructions above the example. It's the whole
expression, including the pswhash = that returns boolean.
I'm sorry about that: I think I need to correct my proposed correction!
I think I've been writing too much C recently, and so I foolishly
mis-read that as returning pswhash, rather than returning the truth of
the comparison.
What I meant to write, for clarity, was:
SELECT (pswhash = crypt('entered password', pswhash)) AS pswmatch FROM ... ;
which would make it obvious that we're returning the boolean named pswmatch.
[Also, should the default example perhaps use gen_salt('bf'), as opposed to
gen_salt('md5') ?]
This, however, might be a good idea. People should of course always
read the documentation, but having the examples including the best
practice would probably be a good idea.
Incidentally, there are 2 other things that confused me in this section.
1. Table F-18. Supported algorithms for crypt() has a column labelled
max password length. It would perhaps also be useful to know the size
of column needed to store the crypted password (my original crypt using
md5 easily fits in a varchar(70), whereas using bf needs the column to
be varchar(100).)
2. Table F-20. Hash algorithm speeds
What's the difference here between crypt-md5 and md5 ?
If I've rightly read this, the algorithm named md5 in the crypt()
documentation is named crypt-md5 here, whereas Table F20's md5
algorithm seems to refer to something else - probably the normal
version of md5.
If so, it would be clearer to write that the last 2 lines (md5 and
sha1) are for comparison only, and refer to the speed of doing an
ordinary md5/sha1 sum, rather than the md5-variant of crypt().
Anyway, thanks again for your help - Postgres is a wonderful system,
which I've found to be repeatedly useful.
Best wishes,
Richard
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] error during the installation with the installer postgresql-9.2.4-1-windows.exe
I got the following error message (pop-up) in the end of PostgreSQL9.2 installation on Windows 7 32-bit machine: Problem running post-install step. Installation may not complete correctly. The database cluster initialization failed. I did the installation by using the downloaded installer postgresql-9.2.4-1-windows.exe. Please help. Thank you, Ovsei Volberg Video Gaming Senior Software Engineer Scientific Games International 1500 Bluegrass Lakes Parkway | Alpharetta, GA 30004 (*) Direct 770.825.4582 (*) ovsei.volb...@scientificgames.commailto:hank.free...@scientificgames.com This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation.
