Max Bowsher m...@f2s.com writes:
On Fri, Aug 20, 2010 at 20:52, Tom Lane t...@sss.pgh.pa.us wrote:
If I understand Max's statements correctly, there is an observable
problem in the actual git history, not just the commit log entries:
it will believe that a file added on a branch had been there
On 20/08/10 21:08, Tom Lane wrote:
Max Bowsher m...@f2s.com writes:
On Fri, Aug 20, 2010 at 20:52, Tom Lane t...@sss.pgh.pa.us wrote:
If I understand Max's statements correctly, there is an observable
problem in the actual git history, not just the commit log entries:
it will believe that a
On Fri, Aug 20, 2010 at 07:59:55PM +0100, Greg Stark wrote:
On Fri, Aug 20, 2010 at 7:34 PM, David Fetter da...@fetter.org wrote:
+1 for three-number versions...well, until we really see the light
and go to two-number versions. 8.3 and 8.4 are different enough
that they shouldn't even
I wrote:
In principle we don't need to sharelock the referencing row in either
update in this example, since the original row version is still there.
s/referencing/referenced/ ... sorry bout that ...
regards, tom lane
--
Sent via pgsql-hackers mailing list
In principle we don't need to sharelock the referencing row in either
update in this example, since the original row version is still there.
The problem is to know that, given the limited amount of information
available when performing the second update.
Ah, ok. I get it now.
Now to figure
Max Bowsher m...@f2s.com writes:
On 20/08/10 21:08, Tom Lane wrote:
I'm still confused as to why this results in such massive weirdness in
the generated git history, though. If it simply caused an extra commit
that adds the new file slightly earlier than the commit we think of as
adding the
On Fri, Aug 20, 2010 at 11:48:12AM -0700, David Wheeler wrote:
On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
No idea what you mean by that, but generally it's a bad idea to
switch from dotted-integer version numbers and numeric version
numbers. See Perl (Quel désastre!).
I'm
On Fri, Aug 20, 2010 at 4:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Max Bowsher m...@f2s.com writes:
On 20/08/10 21:08, Tom Lane wrote:
I'm still confused as to why this results in such massive weirdness in
the generated git history, though. If it simply caused an extra commit
that adds the
* Tom Lane t...@sss.pgh.pa.us [100820 16:28]:
Uh, no, the excitement is about this:
http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=shortlog;h=refs/tags/REL8_3_10
There are a whole lot of commits listed there that have nothing to do
with anything that ever happened on the 8.3
David E. Wheeler da...@kineticode.com writes:
On Aug 20, 2010, at 12:15 PM, Tom Lane wrote:
Well, I for one will fiercely resist adopting any such standard, because
it's directly opposite to the way that RPM will sort such version numbers.
Which is how?
9.0.0 is less than 9.0.0anything.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
David Wheeler:
No idea what you mean by that, but generally it's a bad idea
to switch from dotted-integer version numbers and numeric
version numbers. See Perl (Quel dsastre!).
Yeah, I think Perl is a prime example of how NOT to handle
* Tom Lane t...@sss.pgh.pa.us [100820 17:10]:
BTW, 9.0.0 is also less than 9.0.0.anything ... so sticking another dot
in there wouldn't help.
Debian's packaging versions work around this with the special ~
character, which they define as sorting *before* nothing, meaning
8.4~beta1
On Fri, 2010-08-20 at 21:17 +, Greg Sabino Mullane wrote:
David Fetter:
We're using Postgre 8
See also all the flocks of tools that claim to support Postgres 8
Flocks? Handful at best, and no reason we should be catering to
their inaccuracies.
Depends on the goal. If our goal
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 20, 2010 at 4:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There are a whole lot of commits listed there that have nothing to do
with anything that ever happened on the 8.3 branch.
The problem you are looking at here has been fixed. We are
On Aug 20, 2010, at 2:10 PM, Tom Lane wrote:
9.0.0 is less than 9.0.0anything. Unless you wire some specific
knowledge of semantics of particular letter-strings into the comparison
algorithm, it's difficult to come to another decision, IMO.
That's what Semantic versions do. From the spec's
On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler da...@kineticode.com wrote:
On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
The current system give people the completely false impression that
7.0 and 7.4 are somehow similar.
On what planet?
Look at other DBMSes:
Oracle: 8i, 9i, 10g,
On Fri, Aug 20, 2010 at 04:41:20PM -0500, Jaime Casanova wrote:
On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler da...@kineticode.com
wrote:
On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
The current system give people the completely false impression
that 7.0 and 7.4 are somehow
On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 11
MS SQL Server 7, 2000, 2005, 2008
note the lack of dotes (and even if they actually have dots, those are
minor versions).
So your proposal is
On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 11
MS SQL Server 7, 2000, 2005, 2008
note the lack of dotes (and even if they
On Fri, Aug 20, 2010 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
In any case those are all marketing brand names. The actual releases
do in fact have real version numbers and no, they aren't all minor
releases. Oracle 8i was 8.1.x which was indeed a major release over
8.0.
I wrote:
If there are a lot of user-hostile behaviors there, it might be
worth looking at the possibility of bending the SSI techniques to
that end
In the for what it's worth department, I tried out the current
Serializable Snapshot Isolation (SSI) patch with this test case at
the
On Aug 20, 2010, at 5:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 11
MS SQL
On Fri, Aug 20, 2010 at 23:39, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 20, 2010 at 4:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There are a whole lot of commits listed there that have nothing to do
with anything that ever happened on the 8.3
On 20 August 2010 23:10, Robert Haas robertmh...@gmail.com wrote:
On Aug 20, 2010, at 5:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
Look at
On Fri, 2010-08-20 at 18:10 -0400, Robert Haas wrote:
Maybe we can give marketing brand names to every new version so people
is not confused by numbers...
Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95...
:-)
Not really a comparable argument. I find it
On 20/08/10 18:28, Tom Lane wrote:
Max Bowsher m...@f2s.com writes:
The history that cvs2svn is aiming to represent here is this:
1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
did *not* exist.
2) Later, it was added to trunk.
3) Then, someone retroactively
On 20/08/10 14:36, Robert Haas wrote:
On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander mag...@hagander.net wrote:
I believe Robert had some comments/questions as well :-)
What Magnus means is that I'm a grumpy old developer who complains
about everything.
Anyway, what I noticed was that
On 20/08/10 18:30, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:28, Tom Lane t...@sss.pgh.pa.us wrote:
Max Bowsher m...@f2s.com writes:
The history that cvs2svn is aiming to represent here is this:
1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
did *not* exist.
On 20/08/10 19:07, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:56, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:43, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:41, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:30, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:28, Tom Lane
On 20/08/10 18:43, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:41, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:30, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:28, Tom Lane t...@sss.pgh.pa.us wrote:
Max Bowsher m...@f2s.com writes:
The history that cvs2svn is aiming to represent
On 20/08/10 19:54, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 20:52, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
In fact, is the only thing that's wrong here the commit message?
Because it's probably trivial to just patch that away.. Hmm, but i
guess
On 20/08/10 19:30, Tom Lane wrote:
Max Bowsher m...@f2s.com writes:
My guess at this point is that there may be a (very old?) version of cvs
which, when adding a file to a branch, actually misrecorded the file as
having existed on the branch from the moment it was first added to trunk
- this
Not really a comparable argument. I find it interesting that people are
making logical arguments about something that is clearly not in the
logical realm. This is marketing people.
Then why are we discussing it on -hackers?
--
-- Josh Berkus
Magnus Hagander mag...@hagander.net writes:
I have now pushed a complete copy of the latest migrated repository to
http://git.postgresql.org/gitweb?p=git-migration-test.git;a=summary.
This one has tkey keyword expansion on, which we decided we want. My
script that compares branch tips and
On Fri, 2010-08-20 at 15:41 -0700, Josh Berkus wrote:
Not really a comparable argument. I find it interesting that people are
making logical arguments about something that is clearly not in the
logical realm. This is marketing people.
Then why are we discussing it on -hackers?
Good
(2010/08/20 23:34), Robert Haas wrote:
2010/8/19 KaiGai Koheikai...@ak.jp.nec.com:
(2010/08/20 11:45), Robert Haas wrote:
2010/8/19 KaiGai Koheikai...@ak.jp.nec.com:
I also plan to add a security hook on authorization time.
It shall allow external security providers to set up credential of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Then why are we discussing it on -hackers?
Because you will need buy in from the hackers if you
ever want to do something as radical as change to
a two-number, one dot system (or some the slightly
less radical earlier suggestions). For the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Flocks? Handful at best, and no reason we should be catering to
their inaccuracies.
Depends on the goal. If our goal is to continue to add confusion to the
masses of users we have, you are correct. If our goal is to simplify the
ability
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 11
MS SQL Server 7, 2000, 2005, 2008
is not only confusing but make people think we are somehow behind the
others... someone actually told me that Oracle is in version 11 we
On Sat, 2010-08-21 at 01:31 +, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Flocks? Handful at best, and no reason we should be catering to
their inaccuracies.
Depends on the goal. If our goal is to continue to add confusion to the
masses of
On Sat, 2010-08-21 at 01:36 +, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 11
MS SQL Server 7, 2000, 2005, 2008
is not only confusing but make people think we are somehow behind
On Aug 20, 2010, at 5:38 PM, Greg Sabino Mullane wrote:
Then why are we discussing it on -hackers?
Because you will need buy in from the hackers if you
ever want to do something as radical as change to
a two-number, one dot system (or some the slightly
less radical earlier suggestions).
On Fri, Aug 20, 2010 at 2:12 PM, David E. Wheeler da...@kineticode.com wrote:
Would it be possible to *always* use three integers? So the next release
would be 9.0.0beta5 or 9.0.0rc1? In addition to being more consistent, it
also means that PostgreSQL would be adhering to Semantic Versioning
On Aug 20, 2010, at 7:49 PM, Robert Haas wrote:
I think the semantic versioning approach makes sense for libraries,
but it is not too clear to me that it makes sense for other kinds of
applications. YMMV, of course.
Yeah, I'm more concerned about determining dependencies in extensions and
On Fri, Aug 20, 2010 at 10:43 PM, Joshua D. Drake j...@commandprompt.com
wrote:
True, we don't always have the best track record for bumping major
releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the
idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
It's possible that we're arguing for the sake of arguing
No it's not! ;)
It's nice to be able to keep track of the major version
number without running out of fingers (at least for a few more years)
and it's nice to be able
101 - 146 of 146 matches
Mail list logo
