Re: [BUGS] BUG #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
I based on the documentation of PostgreSQL
(http://www.postgresql.org/docs/9.2/static/datatype-numeric.html#DATATYPE-FLOAT)
which says about 'Infinity' and '-Infinity' and doesn't mention other possible
spellings, including 'inf'.
And on my installation of 9.2.4 'inf' doesn't work too (as I supposed according
to documentation):
SELECT 'inf'::float8
ERROR: invalid input syntax for type double precision: "inf"
LINE 2: SELECT 'inf'::float8
According to Python's documentation
(http://docs.python.org/2/library/stdtypes.html#typesnumeric), handle of
infinities and NaNs was added in 2.6. At least this works in 2.7.1:
Python 2.7.1 (r271:86832, Apr 1 2013, 01:27:27) [MSC v.1600 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> float('inf')
inf
>>> float('infinity')
inf
>>> float('+inf')
inf
>>> float('-inf')
-inf
So, Python is honest in this way. And, C99 says that style of representation
('inf' or 'infinity') is implementation-defined, so it is all OK with modern
Python.
> We already backstop strtod() for these cases:
>
> NaN
> Infinity
> -Infinity
>
> but the wording of the spec clearly requires +Infinity as well as the
> forms with just "inf". (It also appears to require +/- NaN to be
> accepted, but I have no idea what that would mean and suspect it to
> be a thinko.)
As I can judge, signed NaNs are from the same world as signed zeros and signed
infinities. Strictly speaking: (-0)/(+0) is -NaN, (-inf)/(+inf) is -NaN, and so
on.
I think that PostgreSQL's ability to handle signed zeros (and all other rare
stuff) depends on compiler used. Google says me that '-NaN' exists in modern
glibc. I don't know about MSVC. My Python accepts '-nan' as input, but doesn't
give me '-NaN' as output.
So, I think it would be good if '-NaN' and other forms were workable.
--
Best regards,
Basil Peace
--
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 #6652: Installer grants postgres user rights for the whole disk, not specified subfolder
In my case invalid argument (root directory instead of specified data directory) was passed by installer to icacls. That's what I saw. It wasn't problem of icacls, it was a problem in pgsql installer. 05.06.2012, 22:38, "Dave Page" : > On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera > wrote: > >> Excerpts from grv87's message of sáb may 19 10:28:47 -0400 2012: >>> The following bug has been logged on the website: >>> >>> Bug reference: 6652 >>> Logged by: Basil Peace >>> Email address: gr...@yandex.ru >>> PostgreSQL version: 9.1.3 >>> Operating system: Windows 7 x64 >>> Description: >>> >>> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creating >>> database cluster' is too long. I have been waiting for a half of hour, and >>> it hasn't finished. >>> I've noted that installer calls icacls.exe with arguments: >>> D:\ /grant "postgres":RX >> This seems to be reported every once in a while. It looks like the >> one-clunk installer is to blame. Maybe it's been fixed in some more >> recent version -- Dave Page would probably know. > > Just as an FYI, we are working on this. We've been able to reproduce > it, and it appears that icacls (a Microsoft utility) will sometimes > look at the ACL of every file/directory recursively when it grants the > required privileges on higher level directories. The good news is that > in none of the test we've done has it ever modified the ACL on the > wrong thing - it just takes a long time if there are a lot of items on > the filesystem. We've looked at third party alternatives to icacls, > and they seem to exhibit similar traits. We're also going to look into > other ways around the root problem. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
