Just a short note that the first Beta is now available on
ftp.postgresql.org, and, shortly, on the mirrors ...
This isn't a full announce, which will be on Monday ... but please run a
few tests, make sure everything looks okay ...
Marc G. Fournier Hub.Org Networking Services
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed, but my guess is that we are going to introduce shorter varlena
> headers for 8.3. It will hard to reject an optimization like that, and
> that will probably change the disk format for most columns.
Well, several of the proposals that have been m
Robert Treat wrote:
> On Friday 22 September 2006 12:40, Tom Lane wrote:
> > Tom Dunstan <[EMAIL PROTECTED]> writes:
> > > Joshua's original mail suggested that only certain features would go in.
> > > Is that still on the cards, or will other features be considered if
> > > they're ready?
> >
> >
On Friday 22 September 2006 12:40, Tom Lane wrote:
> Tom Dunstan <[EMAIL PROTECTED]> writes:
> > Joshua's original mail suggested that only certain features would go in.
> > Is that still on the cards, or will other features be considered if
> > they're ready?
>
> You'll note that Dave's mail said
FYI, I am traveling to Oxford, England next week, Monday to Friday, to
meet with Simon and Heikki. My Internet connectivity will be irregular.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---
Jie Zhang wrote:
Hi Heikki and all,
I just sent the latest bitmap index patch to the list. I am not sure if
there is any size limit for this mailing list. If you have received my
previous email, please let me know.
Hi Jie,
I know I said I was going to get testing on this months ago but I've
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I guess it is a compatibility change, but weighing compatibility against
> clarity, I am leaning toward clarity. I assume it is this line that
> would be changed:
> _("user lock [%u,%u,%u,%u]"),
You assume wrong ... that has nothing to do with wha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> When initdb is given an invalid (possibly mistyped) locale name, it just
> ...
> /* should we exit here? */
> ...
> I obviously think we should. Why shouldn't we?
+1. This has been on my long-term, low-priority todo list for a while.
Raising
Merlin Moncure wrote:
> On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I don't see the column rename as an
> > > API change issue.
> >
> > How can you possibly claim it's not an API change?
> >
>
> i dunno, i agree with bruce here. we are just
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see the column rename as an
> API change issue.
How can you possibly claim it's not an API change?
i dunno, i agree with bruce here. we are just changing the output of
pg_locks a bit reflectin
On 2006-09-22, Jim Nasby <[EMAIL PROTECTED]> wrote:
> I thought folks might be interested in this... note in particular the
> comment about linux.
I don't believe that either person in that discussion knows what they are
really talking about.
fsync() on FreeBSD does, as is required, force any m
Andrew Sullivan wrote:
On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more useful database. Maybe this list should only be in the
I like
Tom,
> Pretty sure. :) Why the oops? They haven't been mentioned in some PR
> material or something have they?
No, I'd just been confused and thought the patch was submitted before
feature freeze.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadca
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see the column rename as an
> API change issue.
How can you possibly claim it's not an API change?
If you're insistent on this, my recommendation would be to add a new
LOCKTAG value for advisory locks instead of re-using LOCKTAG_USERLOCK.
This w
On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote:
> Except you can put tables (and pretty much all your other objects)
> in a
> schema, one that's presumably named after your application. That
> greatly
> removes the odds of conficts.
Indeed. In our development environment, we store development,
int
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> (b) we put up that pgfoundry module so that there would be a backward
> >> compatible solution. Won't be very backward compatible if the locks
> >> look different in pg_locks.
>
> > But is anyone going to know wh
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (b) we put up that pgfoundry module so that there would be a backward
>> compatible solution. Won't be very backward compatible if the locks
>> look different in pg_locks.
> But is anyone going to know what userlocks is in 1-2 years?
AgentM <[EMAIL PROTECTED]> writes:
> If I want to use these locks, it seems I will have to hard-code some
> offset into each app or hash the schema name and use that as an
> offset :( In any case, I can't imagine the "wtf?" nightmares an
> accidental collision would induce.
That depends enti
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> When initdb is given an invalid (possibly mistyped) locale name, it just
> prints a warning and proceeds with the default locale from the
> environment. Someone already wondered about this before:
> /* should we exit here? */
> if (!ret)
>
On Sep 22, 2006, at 15:00 , [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 01:52:02PM -0400, Jim Nasby wrote:
I thought folks might be interested in this... note in particular the
comment about linux.
...
From: Greg 'groggy' Lehey <[EMAIL PROTECTED]>
Date: June 26, 2006 11:34:12 PM EDT
To:
[EMAIL PROTECTED] writes:
> I don't believe that fsync() on Linux syncs the whole file system
> either.
Indeed. I'd disregard this as coming from someone who knows much
less than he thinks.
(The most likely explanation for his results, I expect, is that FreeBSD
is trying to fsync and the disk dr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'm disinclined to change that, because it would probably break existing
> >> client-side code for little gain.
>
> > I think clarity suggests we should make the heading match the feature,
> > i.e call it "advisor
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> >> An admin who is concerned about this can revoke public access on the
> >> functions for himself ... but should that be the default out-of-the-box
> >> configuration? I f
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Ahh, ok, I didn't realize that the total lock space was larger than
> what's being exposed today. That means we can easily add that stuff in
> the future and not break anything, which is all I was looking for.
Yeah --- in particular, we can always add m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm disinclined to change that, because it would probably break existing
>> client-side code for little gain.
> I think clarity suggests we should make the heading match the feature,
> i.e call it "advisory" rather than "userlock". W
On Fri, Sep 22, 2006 at 01:52:02PM -0400, Jim Nasby wrote:
> I thought folks might be interested in this... note in particular the
> comment about linux.
...
> >From: Greg 'groggy' Lehey <[EMAIL PROTECTED]>
> >Date: June 26, 2006 11:34:12 PM EDT
> >To: leo huang <[EMAIL PROTECTED]>
> >Cc: freebsd
Bruce Momjian wrote:
I created a major features list for 8.2 and put it into CVS. Instead of
going into detail (meaning the item would not appear in the "Changes"
section below, I just highlighted some of the big stuff, and was
purposely vague about the details, so people just have an overview o
Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > advisory locks still show up as 'userlock' in the pg_locks view. does
> > this matter?
>
> I'm disinclined to change that, because it would probably break existing
> client-side code for little gain.
I think clarity suggests we s
> Good afternoon, dear PostgreSQL developers!
>
> First I want to thank all of you for the great DB Server!
> It's really useful, thank you!
>
> Second, here is my question(guys from #postgresql channel
> advised to write to dev list):
>
> I want to make a silent install of PostgreSQL version
Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan <[EMAIL PROTECTED]> wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could proba
On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
> Regardless, I think we should include a section of major new
> projects/developments from pgFoundry, because they ultimately make
> PostgreSQL a more useful database. Maybe this list should only be in the
I like that. "New enhancemen
On Sep 22, 2006, at 14:11 , Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock
Great, all added.
---
Simon Riggs wrote:
> On Thu, 2006-09-21 at 21:45 -0400, Bruce Momjian wrote:
>
> > Let me know how it looks.
>
> Very Good
>
>
>
> Very last, Minor change thoughts:
>
> * Continuous
When initdb is given an invalid (possibly mistyped) locale name, it just
prints a warning and proceeds with the default locale from the
environment. Someone already wondered about this before:
/* should we exit here? */
if (!ret)
fprintf(stderr, _("%s: invalid locale name \"%s\"
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
>> This is why I suggested we set aside some range of numbers that should
>> not be used. Doing so would allow adding a better-managed
>> numbering/na
I thought folks might be interested in this... note in particular the
comment about linux.
Begin forwarded message:
From: Greg 'groggy' Lehey <[EMAIL PROTECTED]>
Date: June 26, 2006 11:34:12 PM EDT
To: leo huang <[EMAIL PROTECTED]>
Cc: freebsd-performance@freebsd.org
Subject: Re: Is the fsync
On Fri, Sep 22, 2006 at 01:42:48PM -0400, Merlin Moncure wrote:
> On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >I'm not asking for a defined solution to how to support multiple
> >different users of locks within the same database. I just want us to set
> >aside (as in, recommend they not b
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
>> This is why I suggested we set aside some range of numbers that should
>> not be used. Doing so would allow adding a better-managed
>> numbering/naming scheme in the future.
> the whole point abou
Tom Lane wrote:
Tom Dunstan <[EMAIL PROTECTED]> writes:
Joshua's original mail suggested that only certain features would go in.
Is that still on the cards, or will other features be considered if
they're ready?
You'll note that Dave's mail said no such thing.
No, but it did explicitly menti
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
I'm not asking for a defined solution to how to support multiple
different users of locks within the same database. I just want us to set
aside (as in, recommend they not be used) some set of numbers so that in
the future we could recommend a me
Josh Berkus wrote:
Tom,
I'm obviously thinking of enums which was ready (for review at least) a
few weeks ago, but has probably bitrotted slightly since then given the
number of patches that have landed in the tree. I intended to brush it
up as soon as the 8.3 tree was open and resubmit it. Wil
Josh Berkus wrote:
I'm obviously thinking of enums which was ready (for review at least) a
few weeks ago, but has probably bitrotted slightly since then given the
number of patches that have landed in the tree. I intended to brush it
up as soon as the 8.3 tree was open and resubmit it. Will that
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
> On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
> >> the whole point about advisory locks is that the provided lock space
> >> is unmanaged. for example, in the I
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
> the whole point about advisory locks is that the provided lock space
> is unmanaged. for example, in the ISAM system I wrote which hooked
> into the acucobol virtual file system i
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
> On Wed, Sep 13, 2006 at 22:22:12 -0700,
> Tom Dunstan <[EMAIL PROTECTED]> wrote:
> >
> > That's a worthwhile point. How many patches come from the general
> > community vs out of the blue? Patches from regulars could probably ge
On Thu, Sep 14, 2006 at 03:41:06 -0700,
Dhanaraj M <[EMAIL PROTECTED]> wrote:
> Is there any utility in postgresql which can do the following?
>
> The utility must update the table whenever there is any change in the
> text file.
> COPY command helps to do that, though this is not straight forw
On Fri, Sep 22, 2006 at 02:16:53PM +0100, Dave Page wrote:
> Following the recent discussion on this list and another on
> pgsql-core, we have decided that we would like to aim to meet the
> following schedule for the release of PostgreSQL 8.3:
>
> April 1st 2007 - Feature freeze
^
We s
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
> On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >This is why I suggested we set aside some range of numbers that should
> >not be used. Doing so would allow adding a better-managed
> >numbering/naming scheme in the future.
>
>
On Sep 22, 2006, at 12:46 , Merlin Moncure wrote:
On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote:
I would be more worried about accidental collisions between
applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to
Good afternoon, dear PostgreSQL developers!
First I want to thank all of you for the great DB Server! It's really
useful, thank you!
Second, here is my question(guys from #postgresql channel advised to write
to dev list):
I want to make a silent install of PostgreSQL version 8.1 using your
Josh Berkus writes:
> Bruce, Dave,
>> This will likely stop people from migrating to 8.2, but so what? It
>> isn't going to stop new users and existing users in real production
>> setting will likely wait for 8.3 anyway.
> And at this point most production users are only upgrading every 2-3
>
On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
the whole point about advisory locks is that the provided lock space
is unm
Tom Lane wrote:
> Matteo Beccati <[EMAIL PROTECTED]> writes:
>> Tom Lane ha scritto:
>>> Matteo Beccati <[EMAIL PROTECTED]> writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
>>> Well, the question is exactly what is "large enough
Tom Dunstan wrote:
Dave Page wrote:
This will obviously be a short development cycle which will allow us to
get some of the features that just missed 8.2 out of the door, as well
as giving us the opportunity to try releasing before the summer (for
those in the northern hemisphere) rather than af
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan <[EMAIL PROTECTED]> wrote:
>
> That's a worthwhile point. How many patches come from the general
> community vs out of the blue? Patches from regulars could probably get a
> free pass, which might cut down the review burden substantially.
An
On 9/22/06, AgentM <[EMAIL PROTECTED]> wrote:
I would be more worried about accidental collisions between
applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to the
current database. this would only be a problem
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Joshua's original mail suggested that only certain features would go in.
> Is that still on the cards, or will other features be considered if
> they're ready?
You'll note that Dave's mail said no such thing.
There has been some talk of trying to agree on
Tom,
I'm obviously thinking of enums which was ready (for review at least) a
few weeks ago, but has probably bitrotted slightly since then given the
number of patches that have landed in the tree. I intended to brush it
up as soon as the 8.3 tree was open and resubmit it. Will that be a
waste of
-Original Message-
From: "Tom Dunstan" <[EMAIL PROTECTED]>
To: "Dave Page"
Cc: "pgsql-hackers@postgresql.org"
Sent: 22/09/06 17:21
Subject: Re: [HACKERS] 8.3 Development Cycle
> will other features be considered if
they're ready?
Yes, normal rules apply, just in a shorter timeframe.
Bruce, Dave,
This will likely stop people from migrating to 8.2, but so what? It
isn't going to stop new users and existing users in real production
setting will likely wait for 8.3 anyway.
And at this point most production users are only upgrading every 2-3
releases anyway (something which
Joachim Wieland <[EMAIL PROTECTED]> writes:
> Appended is a doc patch that removes tables B-4 and B-5 from Appendix B and
> integrates information from there into other parts, mostly into section
> 8.5.3.
Applied with a few minor editorializations.
> I still havent gotten a reply to
> http://arch
Dave Page wrote:
This will obviously be a short development cycle which will allow us to
get some of the features that just missed 8.2 out of the door, as well
as giving us the opportunity to try releasing before the summer (for
those in the northern hemisphere) rather than after.
Joshua's orig
On Fri, Sep 22, 2006 at 12:03:46PM -0400, AgentM wrote:
>
> On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
>
> >On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >>Stephen Frost <[EMAIL PROTECTED]> writes:
> >>> * Tom Lane ([EMAIL PROTECTED]) wrote:
> An admin who is concerned about this
On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> An admin who is concerned about this can revoke public access
on the
>> functions for himself ... but should
there are plenty of other potentially nasty things (like
generate_series and the ! operator). why are advisory_locks handled
specially? the way it stands right now is a user with command access
can DoS a server after five minutes of research on the web.
You don't even have to do any researc
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> advisory locks still show up as 'userlock' in the pg_locks view. does
> this matter?
I'm disinclined to change that, because it would probably break existing
client-side code for little gain.
regards, tom lane
--
On Thu, 2006-09-21 at 21:45 -0400, Bruce Momjian wrote:
> Let me know how it looks.
Very Good
Very last, Minor change thoughts:
* Continuous archiving enhancements
change: Warm Standby enhancements
The improvements to Continuous Archiving relat
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> An admin who is concerned about this can revoke public access on the
>> functions for himself ... but should that be the default out-of-the-box
>> configuration? I
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:26
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Sounds fine, but announcing this now is almost certain to reduce the
number of
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> An admin who is concerned about this can revoke public access on the
>> functions for himself ... but should that be the default out-of-the-box
>> configuration? I feel more comfortable with saying "you have to tu
On Mon, Sep 11, 2006 at 19:05:12 -0400,
Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> I'm not sure how gmp and the others represent their data but my first guess is
> that there's no particular reason the base of the mantissa and exponent have
> to be the same as the base the exponent is interpre
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> That definitely looks weird to me. Unfortunatly, it's way above me wrt
> CVS knowledge. I'm just going to have to live with it and remember to
> delete that part from my diffs...
The weird thing is that it's not happening for other people. Have you
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 22 September 2006 15:35
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 8.3 Development Cycle
>
> > Err right - if you had said this yesterday when we
> discussed the idea I
> > co
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 September 2006 15:26
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.3 Development Cycle
Sounds fine, but announcing this now is almost ce
Dave Page wrote:
>
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: 22 September 2006 15:26
> > To: Dave Page
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] 8.3 Development Cycle
> >
> > Sounds fine, but announcing this now is almost
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 22 September 2006 15:26
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 8.3 Development Cycle
>
> Sounds fine, but announcing this now is almost certain to reduce the
> number of pe
Dave Page wrote:
> Following the recent discussion on this list and another on pgsql-core,
> we have decided that we would like to aim to meet the following schedule
> for the release of PostgreSQL 8.3:
>
> April 1st 2007 - Feature freeze
>
> May 1st 2007 - Beta 1 release
>
> June 1st 2007 - Rel
Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> The main problem I can see with keeping the CTEs outside the rangetable
> is that according to the source, jointree nodes must currently have
> RANGETBLREF nodes as leaf nodes; as I understand it, your suggestion of
> maintaining the CTEs separately wo
Following the recent discussion on this list and another on pgsql-core,
we have decided that we would like to aim to meet the following schedule
for the release of PostgreSQL 8.3:
April 1st 2007 - Feature freeze
May 1st 2007 - Beta 1 release
June 1st 2007 - Release
This will obviously be a shor
Dave Cramer wrote:
>
> On 22-Sep-06, at 3:58 AM, Markus Schaber wrote:
>
> >Hi, Alvaro,
> >
> >Alvaro Herrera wrote:
> >
> I am aware that more recent versions > 8.x have fixed this
> problem, I
> checked the 7.4 release notes but can't see if any of the fixes
> made it
>
On 22-Sep-06, at 3:58 AM, Markus Schaber wrote:
Hi, Alvaro,
Alvaro Herrera wrote:
I am aware that more recent versions > 8.x have fixed this
problem, I
checked the 7.4 release notes but can't see if any of the fixes
made it
into 7.4.
Usually, only critical data loss and security fixes a
On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I suggest again that you ought to be running your basic design
past the list sooner rather than later.
We will be posting it as soon as we can.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax
> > Strangely, if I try to do a "cvs add gram.c", it fails with cvs
> add:
> > `gram.c' added independently by second party I don't know what
> this
> > means. (Why "second party" and not "third party"?). Even if I
> delete
> > gram.c. Even if I remove it from .cvsignore.
>
> I think "cvs add"
Hi, Alvaro,
Alvaro Herrera wrote:
>>> I am aware that more recent versions > 8.x have fixed this problem, I
>>> checked the 7.4 release notes but can't see if any of the fixes made it
>>> into 7.4.
>> Usually, only critical data loss and security fixes are put into the
>> minor updates (e. G. 7.4
Hi Tom,
Thanks for your initial thoughts on this.
On Wed, 2006-09-20 at 20:13 -0400, Tom Lane wrote:
(cut)
> You really can't get away with having the identical representation for
> CTEs and ordinary sub-selects in the range table. For instance, it
> looks like your patch will think that
>
>
85 matches
Mail list logo
