ngs, just leveraging existing functionality a little differently.
--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
o 8.5.
Hard to keep that win32 acl stuff leak free. There is always a cleanup
goto because you need 6 billion objects to answer any question :o
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Attached is a mix of our two patches. How does that look to you?
looks good.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
n the same message becomes far more unlikely.
Also, they end up being more efficient than sha256 by itself.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
wasn't sure if someone wanted that way. I'd suggest
malloc and free if your going to change it. The only time I use an MS
allocater is when a win32 api function specifically states it must be used.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
ToDacl() is the only
function making use of GetUserSid(), so this change won't break
anything. The benefit to this approach over my first suggestion is that
it avoids an unneeded HeapAlloc(sid), CopySid(sid) ... and its cleaner.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://ww
address you tried to free.
Although the FreeSid call causes no harm because its defensive, there is
still the issue of leaking the TOKEN_USER structure.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
) line 807
FreeSid(psidUser) should be HeapFree(GetProcessHeap(), 0, psidUser)
in order to work with my suggested changes in GetUserSid().
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
it is what I
think it is, the problem is with libc not postgres.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
documentation and possibly how
tedious of an API call PQexecParams can be. If anything, using the
parameterized method promotes much better "safer" coding practices, but
currently its at quite a programming effort cost.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com
good idea. I just don't
think it solves any of the interesting problems.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bruce Momjian wrote:
Aleksej Saushev wrote:
The following bug has been logged online:
Bug reference: 4053
Logged by: Aleksej Saushev
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: NetBSD, but this does no matter
Description:libpq document
There is what looks like a bug in 8.3devel. When getting the money type in
binary format from a libpq client, the below error is thrown from the backend:
ERROR: unsupported integer size 8
It appears that the Cash typedef, defined in include/utils/cash.h, has changed
to an int64 (previously a
13 matches
Mail list logo
