Oh, and I build it on top of f92fc4c95ddcc25978354a8248d3df22269201bc
On 20-04-2015 10:36, Svenne Krap wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hi,
I have (finally) found time to review this.
The syntax
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-03-2015 17:18, Svenne Krap wrote:
I still need to check against the standard and I will run it against a
non-trivival production load... hopefully I will finish up my review
shortly after the weekend...
I am still on it, but a little
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
This is a midway review, a later will complete it.
The patch
Patch from message (87d24iukc5@news-spur.riddles.org.uk) fails (tried to
apply on top of ebc0f5e01d2f ), as b55722692 has broken up the line (in
src/backend/optimizer/util/pathnode.c):
pathnode-path.rows = estimate_num_groups(root, uniq_exprs, rel-rows);
After patching the added parameter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 22:18, Jeff Janes wrote:
In Danish, apparently 'AA' 'WA', so two more rows show up.
Yes of course
We have three extra vowels following Z (namely Æ, Ø and Å) and for
keyboard missing those essential keys we have an official
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19-06-2013 17:41, Kevin Grittner wrote:
OK, pushed without the comment.
Works like a charm :)
Svenne
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
Hi All.
I just subscribed to RRReviewers (that should be pronounce with a nice
rolling r-r-reviewers, right?)
As part of my getting up to speed, I tried to build and run test on the
current master 073d7cb513f5de44530f4bdbaaa4b5d4cce5f984
Basically I did:
1) Clone into new dir
2) ./configure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 18:40, Svenne Krap wrote:
Any ideas what might have happened?
After doing some more digging...
My laptop (which runs PostgreSQL 9.2.4 on x86_64-pc-linux-gnu, compiled
by x86_64-pc-linux-gnu-gcc (Gentoo 4.7.3 p1.0, pie-0.5.5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 20:17, Kevin Grittner wrote:
I was surprised to see that an index-test failed.
It works for me. Could you paste or attach some detail?
Gladly, if you tell me what would be relevant to attach :)
I am brand new to the postgresql
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 20:48, Kevin Grittner wrote:
Apologies; I somehow missed the file attached to your initial post.
That's the sort of thing I was looking for.
Aplogy accepted... :)
Having reviewed that, the source code comments indicate it is for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:04, Svenne Krap wrote:
(sk@[local]:5432) [sk] \l
List of databases
Name | Owner | Encoding | Collate | Ctype| Access
privileges
-
Arghh... crappy mailer... I have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:14, Jeff Janes wrote:
But 9.2.4 does pass make check, and only fails if you reproduce
those things manually?
No, I was lazy and used the (distribution-installed) 9.2
I have tried make check on REL_9_2_4 and that fails to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-06-2013 21:41, Svenne Krap wrote:
I will dig futher and get back...
The regression test was added in 9.2, the earliest interesting commit is
d6d5f67b5b98b1685f9158e9d00a726afb2ae789,
where Tom Lane changes the definition to the current
Andrew Dunstan wrote:
Me neither. I wonder how many other long term users (I have used pgsql
for more than a decade - 6.2 was my first version if memory serves)
and have never caught that nuance either.
Maybe that should be printed as a note on the narrative description
pages.. something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rick Vernam wrote:
The reference documentation is *always* intended to be more complete and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.
very well, I did not know that.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David E. Wheeler wrote:
I think that all pages that seem to document particular features
should cross-reference the reference pages in section VI, but not
necessarily vice-versa. I don't think that's asking for a lot. If
you're reading the
It could be useful to have a command that returns the table definition
(like pg_dump -st) from within the query interface. This could be
particularly useful if one doesn't have access to or prefers not to
manipulate results coming from a shell. If I have an API from which to
query the
Mark Mielke wrote:
This presumes that better hashes truly exist. It is basic math to show
that all hashes will include collisions. Ignoring the possibility that
one hash has theoretical better distribution for real documents, the
real benefit of SHA-1 over MD5, is that it has more bits. The
Mark Mielke wrote:
More two or even three different hashes with different collion-points
will strongly increase the security.
No it doesn't unless you are thinking about a security through
obscurity argument.
It is really the same argument on all your questions
If I have a simple table
Mark Mielke wrote:
Svenne Krap wrote:
Mark Mielke wrote:
Svenne Krap wrote:
More two or even three different hashes with different
collion-points will strongly increase the security.
No it doesn't unless you are thinking about a security through
obscurity argument
Your logic is invalid
Heikki Linnakangas wrote:
Mark Mielke wrote:
One must also remember that if you use two hashes, if *either* one of
them is broken in the future so that you can reconstruct the password
from the hash, you're screwed.
That is quite a good argument actually :)
--
Sent via pgsql-hackers mailing
Sam Mason wrote:
Are you a cryptanalyst and are you sure that this doesn't actually make
things worse? I'm sure it gives you a warm fuzzy feeling that it's
*got* to be better, but unless someone has done some hard maths I'm not
sure how you can be so sure.
No sadly I am no cryptoanalyst.
Tom Lane wrote:
In short, I think there's a reasonably good case to be made for losing the
hidden dependency and re-adopting the viewpoint that saying SERIAL is
*exactly* the same as making a sequence and then making a default
expression that uses the sequence. Nothing behind the curtain.
I
Gevik Babakhani wrote:
This may be a dumb question but please bear a moment with me.
About the TODO item “%Allow pg_hba.conf settings to be controlled via
SQL“: If in the future we could configure the settings by SQL commands,
assuming the settings are saved in an internal table, what would be
Tom Lane wrote:
I'm a bit suspicious of proposals that we move either hba or conf into
SQL tables --- one of the main reasons why they are flat files is so
you can still edit them after you've hosed them to the point that the
database won't start or won't let you in. If you don't have a
26 matches
Mail list logo
