On Fri, Feb 25, 2005 at 11:51:40PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> but I also hate to burden the developers with rewriting a lot of
> >> regression tests when their time could be better spent elsewhere.
>
> > Certainly, but I suspect it's just a matter of a
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ... ISTM there's far more use for copying from a query
> result that just copying by index order.
Yeah. The other point is that it's entirely likely that an external
sort will be faster than using an indexscan to produce the sorted order.
If you instea
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> but I also hate to burden the developers with rewriting a lot of
>> regression tests when their time could be better spent elsewhere.
> Certainly, but I suspect it's just a matter of adding ORDER BY to
> everything, which just about anyone (even myself
On Feb 25, 2005, at 10:36 AM, Tom Lane wrote:
"Matthew T. O'Connor" writes:
Are there any big projects are people
working on to get into 8.1?
I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR the
results of mu
On 2005-02-25, "Dave Held" <[EMAIL PROTECTED]> wrote:
> A possibility that I would like to pursue is to keep the staging data
> from the previous day, do a COPY TO, import the new data into
> another staging table with a COPY FROM, then export the fresh
> data with another COPY TO. Then, I can wri
On Fri, Feb 25, 2005 at 04:30:17PM -0800, Jeff Davis wrote:
> On Fri, 2005-02-25 at 18:03 -0600, Jim C. Nasby wrote:
> > On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
> > > Jeff Davis <[EMAIL PROTECTED]> writes:
> > > > I didn't consider that. Is there a reason the regression tests assu
Jim C. Nasby wrote:
> On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
> > Jeff Davis <[EMAIL PROTECTED]> writes:
> > > I didn't consider that. Is there a reason the regression tests assume
> > > the results will be returned in a certain order (or a consistent order)?
> >
> > We use diff
Jim C. Nasby wrote:
> Instead of just being able to specify an index to use, how hard would it
> be to allow COPY TO to work from a generic query instead of just a
> table? That way you wouldn't need to do a diff, you could just export
> only new records. ISTM there's far more use for copying from
Sorry, please disregard my ramblings. I thought it was a different
question.
---
pgman wrote:
> Jim C. Nasby wrote:
> > On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
> > > Jeff Davis <[EMAIL PROTECTED]> writes:
On Fri, 2005-02-25 at 18:03 -0600, Jim C. Nasby wrote:
> On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
> > Jeff Davis <[EMAIL PROTECTED]> writes:
> > > I didn't consider that. Is there a reason the regression tests assume
> > > the results will be returned in a certain order (or a consi
Instead of just being able to specify an index to use, how hard would it
be to allow COPY TO to work from a generic query instead of just a
table? That way you wouldn't need to do a diff, you could just export
only new records. ISTM there's far more use for copying from a query
result that just cop
On Fri, 2005-02-25 at 13:30 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I didn't consider that. Is there a reason the regression tests assume
> > the results will be returned in a certain order (or a consistent order)?
>
> We use diff as the checking tool.
>
Well, that do
On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I didn't consider that. Is there a reason the regression tests assume
> > the results will be returned in a certain order (or a consistent order)?
>
> We use diff as the checking tool.
Doesn't t
* Dave Held ([EMAIL PROTECTED]) wrote:
> A possibility that I would like to pursue is to keep the staging data
> from the previous day, do a COPY TO, import the new data into
> another staging table with a COPY FROM, then export the fresh
> data with another COPY TO. Then, I can write a fast C/C++
"Dave Held" <[EMAIL PROTECTED]> writes:
> I am interested in hacking COPY TO such that one can specify that
> rows are copied in a certain index order. I got as far as=20
> src/backend/commands/copy.c:CopyTo(), and it looks like I would need
> to modify the call to heap_beginscan() so that it uses
Title: Modifying COPY TO
I am interested in hacking COPY TO such that one can specify that
rows are copied in a certain index order. I got as far as
src/backend/commands/copy.c:CopyTo(), and it looks like I would need
to modify the call to heap_beginscan() so that it uses a key. However
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> If this were an ordinary devel cycle then I'd be fine with it running a
> >> year, but I think we really do need to plan for a shorter than normal
> >> cycle so we can clean up 8.0 kinks in a reasonably timely fashion.
>
> > Let's s
Bruce Momjian writes:
> Tom Lane wrote:
>> If this were an ordinary devel cycle then I'd be fine with it running a
>> year, but I think we really do need to plan for a shorter than normal
>> cycle so we can clean up 8.0 kinks in a reasonably timely fashion.
> Let's see how much 8.0 cleanup we nee
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Josh Berkus writes:
> >>> I thought we were trying to get away from a midsummer feature freeze, due
> >>> to
> >>> the general lack of personnel in that season?
>
> > I concur with Josh on this ... that kinda wastes the 'two m
Tom Lane wrote:
> Bruce used to try to describe our releases as being oriented towards some
> particular goal, but I always thought that these were after-the-fact
> descriptions that had nothing to do with the real development process.
> The truth is that individual developers work on what they fee
Jim C. Nasby wrote:
> On Fri, Feb 25, 2005 at 10:49:59AM -0500, Bruce Momjian wrote:
> > I have no idea how to predict what will be in 8.1. I couldn't predict
> > what would be in 8.0 until just before feature freeze, so the idea that
> > we would have any clue about 8.1 is unrealistic.
> >
> > H
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
Hrm, guess it's been too long since I've been subscribed to -current. I
know they're still working bugs out of 5.x, but I attributed that to the
major changes made. One of the big reasons I've been such a fan of FBSD
is the technical direction was set by a g
On Fri, 25 Feb 2005 14:40:25 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> yo mero <[EMAIL PROTECTED]> writes:
> > Hello I saw this :
> > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0247
> > is 8.0.1 Safe ?
>
> No --- at least not the source-code releases. Red Hat's 8.0.1 RPMs
> incl
On Fri, Feb 25, 2005 at 01:27:09PM -0400, Marc G. Fournier wrote:
> On Fri, 25 Feb 2005, Jim C. Nasby wrote:
>
> >On Fri, Feb 25, 2005 at 08:42:51AM -0500, D'Arcy J.M. Cain wrote:
> >>>They complain about release delays and the challenge of organizing
> >>>volunteers, just like us.
> >>
> >>Is the
yo mero <[EMAIL PROTECTED]> writes:
> Hello I saw this :
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0247
> is 8.0.1 Safe ?
No --- at least not the source-code releases. Red Hat's 8.0.1 RPMs
include the patch, and I think the latest community RPMs do too.
> is there a patch ?
ht
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> Josh Berkus writes:
>>> I thought we were trying to get away from a midsummer feature freeze, due to
>>> the general lack of personnel in that season?
> I concur with Josh on this ... that kinda wastes the 'two months of
> summer' when ppl are re
Hello I saw this :
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0247
is 8.0.1 Safe ?
is there a patch ?
thank you
Leonel
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joini
"John Hansen" <[EMAIL PROTECTED]> writes:
> Right, so for the sample SQL I sent earlier, the result would be the same as
> the input?
> That's hardly a working upper/lower
[ shrug... ] It works per the locale definition, which is that only
7-bit-ASCII a-z/A-Z get converted.
The bottom line
> On HPUX 10.20, mbstowcs seems to treat all byte values as
> single-byte characters in C locale, so my sample-of-one says
> that it works everywhere ;-).
Right, so for the sample SQL I sent earlier, the result would be the same as
the input?
That's hardly a working upper/lower
If a charac
Peter Eisentraut wrote:
> Am Freitag, 25. Februar 2005 16:26 schrieb Bruce Momjian:
> > OK, but what about latin1?
>
> The following character set names are specified in the SQL standard and
> therefore somewhat non-negotiable:
>
> SQL_CHARACTER
> GRAPHIC_IRV
> LATIN1
> ISO8BIT
> UTF16
> UTF8
>
Jeff Davis <[EMAIL PROTECTED]> writes:
> I didn't consider that. Is there a reason the regression tests assume
> the results will be returned in a certain order (or a consistent order)?
We use diff as the checking tool.
regards, tom lane
---(end of
Markus Schaber <[EMAIL PROTECTED]> writes:
> Tom Lane schrieb:
>> given the improved support in 8.0 for anonymous record types, we could
>> in theory have the backend invent a record type on-the-fly to match
>> whatever list of OUT parameters a particular function has.)
> It would not be necessari
On Fri, 25 Feb 2005, Tom Lane wrote:
Josh Berkus writes:
Also, what do you think of Simon's plan for a 2-stage feature freeze? Maybe
not so far apart ... maybe a month apart?
I didn't feel a need for it. It's true that the closer we get to
feature freeze, the smaller the patch you should expect
"John Hansen" <[EMAIL PROTECTED]> writes:
>> "It fails on my machine" should not be read as "it doesn't
>> work for anyone".
>> It all depends on how your local mbstowcs() works.
> Ok,... Do you have an example of a system on which it works?
On HPUX 10.20, mbstowcs seems to treat all byte values
On Fri, 2005-02-25 at 12:54 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > (1) Do we care about reverse scans being done with synchronized
> > scanning? If so, is there a good way to know in advance whether it is
> > going to be a forward or reverse scan (i.e. before heap_getne
On Fri, 25 Feb 2005, Peter Eisentraut wrote:
Josh Berkus wrote:
I thought we were trying to get away from a midsummer feature freeze,
due to the general lack of personnel in that season?
Better to do feature freeze with no one around than development or
release preparations with no one around, no?
Marc,
> I missed that ... could you re-summarize?
Sure, Simon proposed that we have a feature freeze for "major features" (like
bitmapped indexes and 2PC) before the feature freeze for "minor
features" (like new system views). The reason being that the major features
need a lot more code che
Josh Berkus writes:
> Also, what do you think of Simon's plan for a 2-stage feature freeze? Maybe
> not so far apart ... maybe a month apart?
I didn't feel a need for it. It's true that the closer we get to
feature freeze, the smaller the patch you should expect to drop on us
sight unseen. Si
> > select upper('æøå');
> > ERROR: invalid multibyte character for locale
> > HINT: The server's LC_CTYPE locale is probably
> incompatible with the database encoding.
>
> > Consequently it seems that is does not work.
>
> "It fails on my machine" should not be read as "it doesn't
> work for
On Fri, 25 Feb 2005, Tom Lane wrote:
Josh Berkus writes:
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?
...
So I'd advocate either freezing in May, or in September.
Well, if you take the summer-vacation argument seriously,
On Fri, 25 Feb 2005, Josh Berkus wrote:
Also, what do you think of Simon's plan for a 2-stage feature freeze?
Maybe not so far apart ... maybe a month apart?
I missed that ... could you re-summarize?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PRO
Josh Berkus wrote:
> I thought we were trying to get away from a midsummer feature freeze,
> due to the general lack of personnel in that season?
Better to do feature freeze with no one around than development or
release preparations with no one around, no?
--
Peter Eisentraut
http://developer.
Josh Berkus writes:
> I thought we were trying to get away from a midsummer feature freeze, due to
> the general lack of personnel in that season?
> ...
> So I'd advocate either freezing in May, or in September.
Well, if you take the summer-vacation argument seriously, then nothing
will get done
Tom,
> Well, if you take the summer-vacation argument seriously, then nothing
> will get done between May and September anyway, so we may as well freeze
> in May ;-)
>
> I'd be happy with saying June 1.
Hey, you and Bruce are the ones who'll get stuck with all the code checking if
nobody else is
Tom,
> As a proposal: feature freeze maybe early summer (June or July), beta
> maybe Aug/Sep, final as always "when it's ready" (maybe Oct/Nov with
> a good tailwind).
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season? I c
Jeff Davis <[EMAIL PROTECTED]> writes:
> (1) Do we care about reverse scans being done with synchronized
> scanning? If so, is there a good way to know in advance whether it is
> going to be a forward or reverse scan (i.e. before heap_getnext())?
There are no reverse heapscans --- the only case wh
On Fri, 2005-02-25 at 13:38 +, Simon Riggs wrote:
> On Fri, 2005-02-25 at 00:34 -0800, Jeff Davis wrote:
> > I had an idea that might improve parallel seqscans on the same relation.
> >
> > If you have lots of concurrent seqscans going on a large relation, the
> > cache hit ratio is very low.
Simon,
Welcome back! Ready to get to work? I need to talk to you about some
stuff
> - When is the next release due?
Each of our previous 4 releases has taken between 11 and 14 months. So,
early 2006 would not be unlikely; however, we have set no dates yet.
> - What will be in relea
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 08:42:51AM -0500, D'Arcy J.M. Cain wrote:
They complain about release delays and the challenge of organizing
volunteers, just like us.
Is there any volunteer organization that's any different? :-)
FreeBSD doesn't seem to suffer much
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
Unless generating the splits requires a non-trivial amount of work, I
see no reason not to have them.
its all automated ... still wish I could figure out a way of splitting off
*just* libppq, since that would drop downloads of the full package
significantl
On Fri, 25 Feb 2005, Peter Eisentraut wrote:
Am Freitag, 25. Februar 2005 15:42 schrieb Marc G. Fournier:
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month d
I wouldn't mind seeing people be a little more vocal on the hackers list
about what they plan to be doing, just so that there's not duplication
of effort. But trying to assemble that into some sort of published
Master Plan sounds to me like just a recipe for making ourselves look
foolish when the
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm happy with the Zen approach of "there is no answer, the code comes
> when it is time" and "HACKERS list IS the process".
> Many people take the lack of a planned release date as clear indication
> that there is no strictly controlled release process, h
Am Freitag, 25. Februar 2005 16:49 schrieb Bruce Momjian:
> I have no idea how to predict what will be in 8.1. I couldn't predict
> what would be in 8.0 until just before feature freeze, so the idea that
> we would have any clue about 8.1 is unrealistic.
A good guess for the features contained in
"Matthew T. O'Connor" writes:
> Are there any big projects are people
> working on to get into 8.1?
I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR the
results of multiple indexes, and finally visit the he
Am Freitag, 25. Februar 2005 16:26 schrieb Bruce Momjian:
> OK, but what about latin1?
The following character set names are specified in the SQL standard and
therefore somewhat non-negotiable:
SQL_CHARACTER
GRAPHIC_IRV
LATIN1
ISO8BIT
UTF16
UTF8
UCS2
SQL_TEXT
SQL_IDENTIFIER
So we have to use LA
Am Freitag, 25. Februar 2005 15:42 schrieb Marc G. Fournier:
> Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
> on past track record, I'd say closer to the 18 month, so figure on June
> '06, with freeze in January of '06 (12 month dev, 6 month beta) ...
> subject to chan
On Fri, Feb 25, 2005 at 10:49:59AM -0500, Bruce Momjian wrote:
> I have no idea how to predict what will be in 8.1. I couldn't predict
> what would be in 8.0 until just before feature freeze, so the idea that
> we would have any clue about 8.1 is unrealistic.
>
> How do other open source projects
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Yea, probably September, but you can't dump a huge feature on us in
> >> August either without having talked about it first, so knowing the date
> >> might not be that helpful.
>
> > I thought we were looking at a 12-18 month cy
"Matthew T. O'Connor" writes:
> One thing to consider while discussing the length of the cycle is what
> features are people planning on putting in? The 8.0 cycle had to be
> long due to the many huge improvements. I'm not aware of any 8.1 plans
> that are that ambitious, so why plan a long c
Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
I agree there is no way to accurately predict such things, however there
was a lon
Tom Lane wrote:
Although we've dropped the idea of letting the ARC problem drive a very
short 8.1 cycle, I would still like to see us shoot for a relatively
short 8.1 cycle --- less than a year for sure. The main reason is that
I think we'll be flushing out performance and feature issues in the
Wi
I would agree that since we have a number of commercial developers who
do have intentions of working on specific items in 8.1, it would be nice
to list those items somewhere (the urgent section of the TODO seems
fine), but it is up to those developers to speak up.
I'd like to bundle pg_dump and pg_
On Fri, 2005-02-25 at 05:34, Simon Riggs wrote:
> I'm giving a talk next week on PostgreSQL 8, so I would like some input
> from the community on a few issues, so that my answers are as close to
> majority opinion as possible.
>
> One of the most frequent set of questions I get asked is around the
Simon Riggs wrote:
> I'm giving a talk next week on PostgreSQL 8, so I would like some input
> from the community on a few issues, so that my answers are as close to
> majority opinion as possible.
>
> One of the most frequent set of questions I get asked is around the
> development vision and rel
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> Yea, probably September, but you can't dump a huge feature on us in
>> August either without having talked about it first, so knowing the date
>> might not be that helpful.
> I thought we were looking at a 12-18 month cycle for 8.1? Which would pu
On Fri, Feb 25, 2005 at 08:42:51AM -0500, D'Arcy J.M. Cain wrote:
> > They complain about release delays and the challenge of organizing
> > volunteers, just like us.
>
> Is there any volunteer organization that's any different? :-)
FreeBSD doesn't seem to suffer much from either issue. Then aga
Marc G. Fournier wrote:
> On Fri, 25 Feb 2005, Bruce Momjian wrote:
>
> > Simon Riggs wrote:
> >> On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
> >>> For development, this means we will _not_ have a shortened, non-initdb
> >>> 8.1 release but a regular release cycle with the typical big
Marc G. Fournier wrote:
> On Fri, 25 Feb 2005, Simon Riggs wrote:
>
> > - When is the next release due?
>
> Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
> on past track record, I'd say closer to the 18 month, so figure on June
> '06, with freeze in January of '06 (
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> I think this is what we should do:
>>
>> UNICODE => UTF8
>> ALT => WIN866
>> WIN => WIN1251
>> TCVN => WIN1258
> OK, but what about latin1?
I think LATIN1 is fine as-is. It's a reasonably popular name for the
character set, and despite Tatsuo'
Peter Eisentraut wrote:
> Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
> > so I see what he is saying. We are not consistent in favoring the
> > official names vs. the common names.
> >
> > I will work on a patch that people can review and test.
>
> I think this is what we should do:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> We'll obviously want to fix this going forward for efficiency reasons,
>> but it's an initdb-forcer because it'll change the on-disk
>> representation of time columns. So we can't change it in 8.0 or before.
> So, will we do it? I can do, but I don't k
Urgh. This is clearly a bug. All the code in utils/adt seems to be
correctly set up to treat TimeADT as an integral value, but then the two
macros quoted are converting the value to float8 and back again ... so
what's actually on disk is the float8 equivalent of what the int64 value
is supposed t
"John Hansen" <[EMAIL PROTECTED]> writes:
>> Sure it does. It's just that the defined behavior of the C
>> locale is often useless in practice.
> select upper('æøå');
> ERROR: invalid multibyte character for locale
> HINT: The server's LC_CTYPE locale is probably incompatible with the
> datab
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> 1. Executing outside the database engine, and therefore being able to
>> start/commit transactions. (This is *fundamentally* different from our
>> current concept of functions, and I think that any implementation that
>> tries to gloss over the diffe
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Essentially I'm thinking about the JDBC solution, but automated a bit
>> better.
> So would your proposal invent a new "stored procedure" construct, or
> just add some sugar to the existing function stuff? i.e. will you be
> able to is
On Thu, Feb 24, 2005 at 10:27:03PM +0100, Ernst Herzberg wrote:
> On Thursday 24 February 2005 21:43, Marc G. Fournier wrote:
> [...]
> > >
> > > pub/source/v.8.0.1/
> > > postgresql-8.0.1.tar.bz2
> > > postgresql-8.0.1.tar.bz2.md5
> > > postgresql-8.0.1.tar.gz
>
On Fri, 25 Feb 2005, Simon Riggs wrote:
- When is the next release due?
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| "Francisco Figueiredo Jr." <[EMAIL PROTECTED]> writes:
|
|>Could I add another item?
|
|
|>Could we have the row count of statements executed inside a
|>procedure/function returned to client?
|
|
| IMHO that request is completely bogus
On Fri, 2005-02-25 at 00:34 -0800, Jeff Davis wrote:
> I had an idea that might improve parallel seqscans on the same relation.
>
> If you have lots of concurrent seqscans going on a large relation, the
> cache hit ratio is very low. But, if the seqscans are concurrent on the
> same relation, ther
On Thu, 24 Feb 2005 23:00:48 -0500 (EST)
Bruce Momjian wrote:
> I read the following report from the NetBSD group:
>
> http://kerneltrap.org/node/4680
>
> It has some interesting points. First, they analyze how the fit with
> other open source database offerings. Their position is somewh
> 1. Executing outside the database engine, and therefore being able to
> start/commit transactions. (This is *fundamentally* different from
our
> current concept of functions, and I think that any implementation that
> tries to gloss over the difference will be doomed to failure.)
Back in the ea
On Fri, 2005-02-25 at 00:18 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
> > > For development, this means we will _not_ have a shortened, non-initdb
> > > 8.1 release but a regular release cycle with the typical big batch of
> > > fea
On Fri, 2005-02-25 at 02:47 -0400, Marc G. Fournier wrote:
> On Fri, 25 Feb 2005, Bruce Momjian wrote:
>
> > Simon Riggs wrote:
> >> On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
> >>> For development, this means we will _not_ have a shortened, non-initdb
> >>> 8.1 release but a regular
On Thu, 24 Feb 2005 22:18:11 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Didn't we do that already?
No :( I promised to do it a couple of weeks ago but could not get to do it.
Now with Magnus's help I finaly did it. The last patch should be fine.
> regards, tom lane
Nic
Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta f
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.
One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.
-
Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
> so I see what he is saying. We are not consistent in favoring the
> official names vs. the common names.
>
> I will work on a patch that people can review and test.
I think this is what we should do:
UNICODE => UTF8
ALT => WIN866
WIN =>
On Thu, 2005-02-24 at 23:51 -0500, Bruce Momjian wrote:
> Tatsuo Ishii wrote:
> > I do not object the changing UNICODE->UTF-8, but all these discussions
> > sound a little bit funny to me.
> >
> > If you want to blame UNICODE, you should blame LATIN1 etc. as
> > well. LATIN1(ISO-8859-1) is actuall
> >Are you verifying that all the data that was committed was actually stored?
> >Or
> >just verifying that the database works properly after rebooting?
>
> I verified the data.
Does pg startup increase the xid by some amount (say 1000 xids) after crash ?
Else I think you would also need to rol
> John Hansen wrote:
> > currently, upper/lower does not work with 2+ byte unicode
> characters,
> > on any OS under the C locale.
>
> Sure it does. It's just that the defined behavior of the C
> locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for
I had an idea that might improve parallel seqscans on the same relation.
If you have lots of concurrent seqscans going on a large relation, the
cache hit ratio is very low. But, if the seqscans are concurrent on the
same relation, there may be something to gain by starting a seqscan near
the page
92 matches
Mail list logo
