Lamar Owen <[EMAIL PROTECTED]> writes:
> On Saturday 16 November 2002 01:07, Christopher Kings-Lynne wrote:
> > OK sorry - I was under the impression that core == commit bit...
>
> committers != core
Is there any reason for this distinction?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> ||
On Saturday 16 November 2002 01:07, Christopher Kings-Lynne wrote:
> > I will reiterate for the new folks that the core group doesn't do much
> > more than decide if the final release will be on a Friday or a Monday,
> > and deal with private issues like discipline. I think we deal with such
> > i
> I will reiterate for the new folks that the core group doesn't do much
> more than decide if the final release will be on a Friday or a Monday,
> and deal with private issues like discipline. I think we deal with such
> issues perhaps 2-4 times a year.
OK sorry - I was under the impression that
Applied. Sorry I missed this one. I did a clean compile and initdb for
testing, but forgot regression.
---
Neil Conway wrote:
> Seems like a result of Alverro's cluster patch -- looks like the patch
> didn't updated the ex
At least that is an FAQ item.
---
Jason Tishler wrote:
> Tom,
> Peter,
>
> On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote:
> > On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote:
> > > If you can detect
Lamar Owen wrote:
> On Friday 15 November 2002 10:23, Tom Lane wrote:
> > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > > To the rest of the hackers, is it normal practice to perhaps vote in a
> > > new member of the steering committee?
> >
> > Uh ... it's never happened before ... so t
On Fri, 15 Nov 2002, Mikheev, Vadim wrote:
> Just wonder how are you going to implement it - is it by using
> some kind of "read-locks", ie FK transaction "locks" PK to prevent
> delete (this is known as "pessimistic" approach)?
> About two years ago we discussed with Jan "optimistic" approach
> w
On Fri, 15 Nov 2002, Manfred Koizar wrote:
> On Wed, 13 Nov 2002 14:22:51 -0800 (PST), Stephan Szabo
> <[EMAIL PROTECTED]> wrote:
> >Right now, I know that it has a hole that lets through invalid data
>
> Stephan, your patch has been posted to -general (Subject: Re:
> [GENERAL] Help..Help...). Is
Rod Taylor <[EMAIL PROTECTED]> writes:
> I'd like to split cluster_rel() in cluster.c into 2 functions at line
> 174. The permission checks, locking, etc will remain in cluster_rel().
> The bottom half will be turned into a function called
> rebuild_rel(tableOid Oid, indexOid Oid, dataCopy bool).
I've gotten really tired of explaining to newbies why stuff involving
char(n) fields doesn't work like they expect. Our current behavior is
not valid per SQL92 anyway, I believe.
I think there is a pretty simple solution now that we have pg_cast:
we could stop treating char(n) as binary-equivalen
On Wed, 13 Nov 2002 14:22:51 -0800 (PST), Stephan Szabo
<[EMAIL PROTECTED]> wrote:
>Right now, I know that it has a hole that lets through invalid data
Stephan, your patch has been posted to -general (Subject: Re:
[GENERAL] Help..Help...). Is this version still valid?
> void
> heap_mark4fk_lock_
On Fri, 15 Nov 2002, Thomas Lockhart wrote:
> Just a quick note to mention that I've resigned from the PostgreSQL
> steering committee. It has been a lot of fun and very rewarding to
> participate in PostgreSQL development over the last six years, but it is
> time to take a break and to move on to
Ok. Transaction safe truncate is simply transaction safe cluster
without the data copy and a slightly different set of permission checks.
I'd like to split cluster_rel() in cluster.c into 2 functions at line
174. The permission checks, locking, etc will remain in cluster_rel().
The bottom half
Tom,
Peter,
On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote:
> On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote:
> > If you can detect that cygipc is not running, then ENOSYS seems the
> > best choice for reporting that. (ENOSPC would be misleading too.)
>
> Thanks for your
On Thu, 2002-11-14 at 06:52, Evgen Potemkin wrote:
> Hi there!
>
> I want to propose the patch for adding the hierarchical queries posibility.
> It allows to construct queries a la Oracle for ex:
> SELECT a,b FROM t CONNECT BY a PRIOR b START WITH cond;B
Great addition. But please use the SQL 99
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I find that two geometry 'expected' files are now sufficient to cover
>> all the platforms I have available to test. (We'd only need one, if
>> everyone displayed minus zero as '-0', but some platforms print '0'.)
> Judging from t
Seems like a result of Alverro's cluster patch -- looks like the patch
didn't updated the expected results for the regression tests
fully. Diffs below.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
*** ./expected/cluster.out Fri Nov 15 12:35:36 2002
--- ./results
On Friday 15 November 2002 10:23, Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > To the rest of the hackers, is it normal practice to perhaps vote in a
> > new member of the steering committee?
>
> Uh ... it's never happened before ... so there is no "normal practice".
Tom Lane writes:
> I find that two geometry 'expected' files are now sufficient to cover
> all the platforms I have available to test. (We'd only need one, if
> everyone displayed minus zero as '-0', but some platforms print '0'.)
Judging from the platforms affected by this, I would suspect that
On Friday 15 November 2002 01:38, Thomas Lockhart wrote:
> Just a quick note to mention that I've resigned from the PostgreSQL
> steering committee. It has been a lot of fun and very rewarding to
> participate in PostgreSQL development over the last six years, but it is
> time to take a break and t
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > To the rest of the hackers, is it normal practice to perhaps vote in a new
> > member of the steering committee?
>
> Uh ... it's never happened before ... so there is no "normal practice".
The logic usually has been to ad
On Wed, 2002-11-13 at 23:37, Philip Warner wrote:
> At 02:53 PM 13/11/2002 -0500, Rod Taylor wrote:
> >I can make a complete list tonight of whats captured.
>
> Sounds good
Below is a summary of what pg_depend tracks that might be useful.
Skipped a number of dependencies that are internal only (
Marc G. Fournier wrote:
At this point, we are looking for confirmation that all the platforms are
building and running the regression tests correctly, and, unless any major
bug reports are submitted, any further changes to this branch will be
either documentation related, or tweaks to ensure as m
[EMAIL PROTECTED] wrote in message
news:<[EMAIL PROTECTED]>...
> Hello,
> I know Ansi C language and SQL. I want to embed a sql statement into a c
> source code. Would you please recommend me some web sites or tutorials
> regarding this subject.
> Thank you for your concern,
> Emrah
>
>
> ---
On Fri, 15 Nov 2002, Zeugswetter Andreas SB SD wrote:
>
> > Problem is when I want change view (or functions) with a lot of dependecies
> > I must drop and recreate all dependent views (or functions) -
> > I want add only one column in view
> > I don't know if solution hard for that.
>
> I do not
Hi Marc,
On Fri, 8 Nov 2002 at 09:59, Marc G. Fournier wrote:
> At this point, we are looking for confirmation that all the
> platforms are building and running the regression tests correctly,
v7.3b5 builds and passes the testsuite under SuSE Linux on the
following platforms:
i386, ia64
Hi there!
I want to propose the patch for adding the hierarchical queries posibility.
It allows to construct queries a la Oracle for ex:
SELECT a,b FROM t CONNECT BY a PRIOR b START WITH cond;B
I've seen this type of queries often made by adding a new type, which stores
position of row in the tr
You're right, it was a hardware problem.
Thanks for your help.
Nicolas VERGER
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED]] De la part de scott.marlowe
> Envoyé : mercredi 6 novembre 2002 21:38
> À : Nicolas VERGER
> Cc : 'PostgreSQL Hackers Ma
I've tested this under 7.3, and it works beautifully for the cases I've
built over the last 2 days. I can no longer bugger a plan up mearly
by reordering the WHERE clauses. Note that 2 of the five parts won't
patch in (involving constantqual). Looks to be code refactoring between
here and planmain.
Hey Thomas,
Although we have never corresponded, I just wanted to say thank you to
yourself and all the other hackers who have devoted their time voluntarily to
PostgreSQL. It really is appreciated.
Cheers
Mark Pritchard
On Fri, 15 Nov 2002 17:38, Thomas Lockhart wrote:
> Just a quick note to
> > Scott you're right, it was a hardware problem.
> > Thanks for your help.
> >
>
> Glad to be of help. What was the problem? Bad memory or bad hard
drive?
> Just curious.
It was a bad 512Mo memory module and a bad memory slot on the
motherboard.
Our hosting provider never checks memory before
Hi there!
I want to propose the patch for adding the hierarchical queries posibility.
It allows to construct queries a la Oracle for ex:
SELECT a,b FROM t CONNECT BY a PRIOR b START WITH cond;B
I've seen this type of queries often made by adding a new type, which stores
position of row in the tre
Josh,
Thanks for the reply. Much of what you say is as we expected.
I see that 7.3 has addressed the "Unable to identify an operator
'=' for types 'numeric' and 'double precision'" problem, but
I'm not sure how. Context-sensitive approach? Overloaded operator
approach? Something else ( is the
> Wouldn't it work for cntxDirty to be set not by LockBuffer, but by
> XLogInsert for each buffer that is included in its argument list?
I thought to add separate call to mark context dirty but above
should work if all callers to XLogInsert always pass all
modified buffers - please check.
Vadim
Hi guys,
I have searched high and low to find a definitive answer and so far have
only found lots of discussion about the pros and cons of the subject :
Simply, is/will there in the future be a facility to return immediately from
"select for update" with an error message if the row is locked, a
On Sun, 10 Nov 2002 16:29:03 -0600
GB Clark <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Well the subject says it all. It was there in the last beta I was testing
> which was beta 1.
>
> Am I being dense here, or is it really missing?
>
> Thanks,
>
> GB
It was me being dense! It has been removed.
I have been experimenting with empirical tests of file system and device
level writes to determine the actual constraints in order to speed up the WAL
logging code.
Using a raw file partition and a time-based technique for determining the
optimal write position, I am able to get 8K writes physical
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> To the rest of the hackers, is it normal practice to perhaps vote in a new
> member of the steering committee?
Uh ... it's never happened before ... so there is no "normal practice".
regards, tom lane
---
On Thu, 14 Nov 2002, Patrick Welche wrote:
> Believe it or not, I'm trying to compile today's cvs pgsql on a
> Debian 2.2.19 system. Compilation dies while compiling pg_dump with
>
> ../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit'
>
> In the mail archives there is a menti
> Problem is when I want change view (or functions) with a lot of dependecies
> I must drop and recreate all dependent views (or functions) -
> I want add only one column in view
> I don't know if solution hard for that.
I do not see how adding a column to a view would invalidate
dependent obje
> -Original Message-
> From: Thomas Lockhart [mailto:[EMAIL PROTECTED]]
> Sent: 15 November 2002 06:38
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Time to move on...
>
>
> Just a quick note to mention that I've resigned from the PostgreSQL
> steering committee. It has been a lot of f
41 matches
Mail list logo