Tom Lane wrote:
Granted, the script itself is faulty, but since some other OS projects
(like Ruby, with the same x.y.z numbering) do guarantee they never will
have double digits in version number component
Oh? What's their plan for the release after 9.9.9?
As for Ruby, it probably won't expect >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I understand. You are saying that we couldn't set the date until May 1,
> but on May 1 we should have set the date farther way, like 6-8 weeks,
> rather than 4.5 weeks, right?
I think there are a couple of important points in this discussion.
One is th
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >I believe the decision for June 1 was made around May 1. I participated
> >in the discussion. Should we have made that final decision sooner?
> >
> >
> >
>
> No, I think that was the right time to make a decision. Before that
> things we
Lamar Owen wrote:
Please lighten up, that's all. That's one thing I have found helps in this
project, and maybe it's not something I made clear, but we are 'laid back'
including a fair amount of humor. A good portion of that goes on privately;
I remember ribbing Bruce a couple of cycles back
On Saturday 05 June 2004 10:13, Andrew Dunstan wrote:
> Lamar Owen wrote:
> >There is a reason I wrote the message a long time ago (that, I think, is
> > still in the Developer's FAQ) about how to get started in PostgreSQL
> > development. The first thing a developer should do before getting too
>
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there should
be some minimum time (I suggested 6 weeks to 2
How about,
"Allow outside agents to extend the GUC variable set"
- thomas
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: "Joe Conway" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>;
"Peter Eisentraut" <[EMAIL PROTECTED]>
"Nicolai Tufar" <[EMAIL PROTECTED]> writes:
> Sorry for rising up old issue again but the problem still persists.
> And database cluster is not being created with Turkish locale
I've committed the attached fix, which I believe will solve this
problem. Could you test it?
(Patch is against 7.4 bra
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sat, 2004-06-05 at 13:31, Tom Lane wrote:
>> Only if you want to require a hash opclass to supply ordering operators,
>> which sort of defeats the purpose I think. Hash is only supposed to
>> need equality not ordering.
> Is it possible to assume some k
On Sat, 2004-06-05 at 13:31, Tom Lane wrote:
> Only if you want to require a hash opclass to supply ordering operators,
> which sort of defeats the purpose I think. Hash is only supposed to
> need equality not ordering.
Is it possible to assume some kind of ordering (i.e. strcmp() the binary
data
Marc G. Fournier wrote:
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there
should be some minimum time (I suggested 6 weeks to 2 months) between
when the decision is made
Tom Lane wrote:
Why not just use the syntax of the insert values with parens?
insert into tble values (...);
is very familiar so the corresponding:
insert into table values ( 'xxx', ('yyy', 123), 456 );
is also easy to understand and remember: a row is being inserted.
I don't particularly car
Good reason. Now I'm excited. I'll download and run
tests and try to do a write up in general bits next week.
cheers,
elein
On Sat, Jun 05, 2004 at 05:00:24PM -0400, Tom Lane wrote:
> I wrote:
> > regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
>
> BTW, I forgot to ment
I wrote:
> regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
BTW, I forgot to mention that the keyword ROW is optional as long as
you've got at least two items in the row expression, so the above can
be simplified to
regression=# insert into bar values (((1.1, 2.2), (3.3,4.
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there should
be some minimum time (I suggested 6 weeks to 2 months) between when the
decision is made/announced and the actual
David Garamond <[EMAIL PROTECTED]> writes:
> Granted, the script itself is faulty, but since some other OS projects
> (like Ruby, with the same x.y.z numbering) do guarantee they never will
> have double digits in version number component
Oh? What's their plan for the release after 9.9.9?
In p
Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
> This is probably a crazy idea, but is it possible to organize the data
> in a page of a hash bucket as a binary tree ?
Only if you want to require a hash opclass to supply ordering operators,
which sort of defeats the purpose I think. Hash is on
elein <[EMAIL PROTECTED]> writes:
> Composite types will work recursively, right?
> That is a composite type inside of a composite type column?
You can have that, but I'm not intending that the I/O syntax be
explicitly aware of it. A composite type field would just be an
item (and hence would hav
Dave Page wrote:
From: David Garamond
Sent: Sat 6/5/2004 9:28 AM
Cc: postgresql advocacy; [EMAIL PROTECTED]
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> This means that if you have only one or a few items per
Tom> bucket, the information density is awful, and you lose big on
Tom> I/O requirements compared to a btree index. On the other
Tom> hand, if you have enough items per
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> There seems to be something seriously defective with hash indexes in old
> versions of PostgreSQL.
They still suck; I'm not aware of any situation where I'd recommend hash
over btree indexes in Postgres. I think we have fixed the hash indexes'
deadlock
Bruce Momjian wrote:
I believe the decision for June 1 was made around May 1. I participated
in the discussion. Should we have made that final decision sooner?
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Why not use standard C semantics for the textual representation with
your addition that empty items are NULL?
This isn't C, it's SQL; and I think the array I/O representation is a
closer precedent for us than the C standard.
In any case,
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
All I have asked for is a) reasonable clarity and b) reasonable notice.
I do not see that either of those conflict with being laid-back or
anything else above.
Something we definitely will work on, in both cases ...
Marc G. Fournier Hub.Org
Composite types will work recursively, right?
That is a composite type inside of a composite type column?
Does the SQL dot syntax support this nested referencing?
Or are we only allowing one level.
Why not just use the syntax of the insert values with parens?
insert into tble values (...
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Why not use standard C semantics for the textual representation with
> your addition that empty items are NULL?
This isn't C, it's SQL; and I think the array I/O representation is a
closer precedent for us than the C standard.
In any case, how much o
Tom Lane wrote:
I am inclined to define this similarly to the representation for arrays;
however, we need to allow for NULLs. I suggest
{item,item,item}
The separator is always comma (it can't be type-specific since the items
might have different types). Backslashes and double quotes can
Andrew Dunstan wrote:
> >But following through a cycle or two in the archives provides ample evidence
> >for the 'laid-back' model used here. It's ready when it's ready. We try to
> >schedule, but the schedules are pretty flexible.
> >
> >And while most discussion happens here on [HACKERS], not
Lamar Owen wrote:
On Tuesday 01 June 2004 22:15, Andrew Dunstan wrote:
Lamar Owen wrote:
Well, it should not have surprised anyone. We have targeted June 1 as a
beta freeze date for several versions, not just 7.5. In fact, looking
back through last year's pre-7.4 discussion, it's deja vu
There's just one thing left to do to make composite types useful as
table columns: we have to support I/O of composite values. (Without
this, pg_dump would fail to work on such columns, rendering them not
very useful in the real world.) This means we have to hammer out a
definition for what the e
From: David GaramondSent: Sat 6/5/2004 9:28 AMCc: postgresql advocacy; [EMAIL PROTECTED]Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year), then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to 8.0
Ð ÐÐÑ, 05.06.2004, Ð 10:28, David Garamond ÐÐÑÐÑ:
> This probably has been discussed and is probably a very minor point, but
> consider how many more years we want to be able to use the digit>. major release numbering.
>
> Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
> t
Some very good suggestions where made here. What happens next? Will this end
up in a TODO list where someone can "claim the task" (I'm trying to learn
how the process works) ?
Kind regards,
Thomas Hallgren
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Joe Conway" <[EMAI
This probably has been discussed and is probably a very minor point, but
consider how many more years we want to be able to use the . major release numbering.
Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip t
34 matches
Mail list logo
