Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> I don't think we want a branch for 7.4 yet. We still have lots of open
>> issues and the branch will require double-patching.
> Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
> released.
Why is that be
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sun, 29 Sep 2002, Tom Lane wrote:
>> This seems far outside pg_config's charter.
> Obviously he wants a tool that allows setting parameters from a shell
> script or something for use within pg_autotune. I don't see why it is
> bad to have a tool to
Marc G. Fournier wrote:
>
> can you create a project on gborg under 'server modules' for this?
Uh, I don't see the logic in moving earthdistance out of /contrib. It
uses /cube, which is in contrib. I didn't think we were moving loadable
modules out to gborg yet, and I didn't think we were doin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I implemented "ADD ONLY" as a way to add the column only in the parent
> (all children should already have to column, errors if at least one
> doesn't or is different atttype), while "ADD" adds the column to
> children that don't have it and merges wher
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I agree with Bruce and Tom.
AFAIK Bruce and Tom (and myself) agree that this is a good idea,
provided it makes a noticeable performance difference (and if it
doesn't, it's not worth applying).
> AFAIK and in my experience I don't think it will be
Neil,
I agree with Bruce and Tom. AFAIK and in my experience I don't think it
will be a significantly measurable increase. Not only that, but the
portability issue itself tends to make it less desireable. I recently
ported SAP DB and the coinciding DevTools over to OpenBSD and learned again
fi
can you create a project on gborg under 'server modules' for this?
On Sun, 29 Sep 2002, Bruce Momjian wrote:
>
> Marc, I am still seeing these errors. Would you please fix it?
>
> ---
>
> Bruce Momjian wrote:
> > I am gett
I read a good article about the problem Intel is having with the 64-bit
Itanium. I think there are some good leasons in the article:
http://www.nytimes.com/2002/09/29/technology/circuits/29CHIP.html
There is also a Slashdot discussion about the article:
http://slashdot.org/arti
Peter, the author is questioning why his Makefile changes were wrong.
Would you elaborate?
---
pgman wrote:
>
> Done.
>
> ---
>
> Peter Eisentraut
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I don't think we want a branch for 7.4 yet. We still have lots of open
> > issues and the branch will require double-patching.
>
> Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
> released.
Yes, there is something to b
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> OK, personally, I would like to see an actual speedup of PostgreSQL
> >> queries before I would apply such a OS-specific, version-specific
> >> patch.
>
> > Don't be silly. A performance i
Bruce Momjian writes:
> I don't think we want a branch for 7.4 yet. We still have lots of open
> issues and the branch will require double-patching.
Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.
--
Peter Eisentraut [EMAIL PROTECTED]
---
On Mon, 2002-09-30 at 00:05, Alvaro Herrera wrote:
> On 29 Sep 2002, Hannu Krosing wrote:
>
> > On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
> > > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > > I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> > > > from the (grand)child)
On Sat, 28 Sep 2002 19:20:43 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>OK, that is a good example. It would return the sum of the matching
>tags. You are suggesting here that it would be better to take the
>result of the last matching tag command, right?
The examples were meant to
Hi,
Now that the ODBC driver has moved from the main distro to
http://gborg.postgresql.org/project/psqlodbc/, we can no longer use the
main build system under *nix.
Can someone who knows make better than I (which is probably the vast
majority of you!) knock up a makefile so the driver will build
On 29 Sep 2002, Hannu Krosing wrote:
> On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> > > from the (grand)child) whereas plain ADD would leave attislocal alone.
> >
> > ADD ON
On Sun, 2002-09-29 at 19:28, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > The initial Postgres design had a notion of StorageManager's, which
> > should make this very easy indeed, if it had been kept working .
>
> But the storage manager interface was never built to hide issue
> -Original Message-
> From: CoL [mailto:[EMAIL PROTECTED]]
> Sent: 24 September 2002 13:23
> To: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Web site
>
>
> Hi,
>
> >>So, why not just redirect people to one of the mirrors listed? This
> >>could be done based on IP (yes it is inaccura
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> > from the (grand)child) whereas plain ADD would leave attislocal alone.
>
> ADD ONLY? There is no such animal as ADD ONLY, and cann
Joe Conway wrote:
>
> Alvaro Herrera wrote:
> > Obviously he wants a tool that allows setting parameters from a shell
> > script or something for use within pg_autotune. I don't see why it is
> > bad to have a tool to do this; if someone can use it (and modify
> > postgresql.conf) obviously he h
Alvaro Herrera wrote:
> Obviously he wants a tool that allows setting parameters from a shell
> script or something for use within pg_autotune. I don't see why it is
> bad to have a tool to do this; if someone can use it (and modify
> postgresql.conf) obviously he has permission to read (and writ
On Fri, Sep 27, 2002 at 09:53:02AM -0700, Joe Conway wrote:
> It is in 7.3.
>
> If the return tuple definition is fixed:
> instead of:
> exec sp_myproc()
> go
> do
> select * from sp_myproc();
That's a great feature to have.
> If the return tuple definition is *not* fixed:
> do
>
On Sun, 29 Sep 2002, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> > from the (grand)child) whereas plain ADD would leave attislocal alone.
>
> ADD ONLY? There is no such animal as ADD ONLY, and cannot be b
On Sun, 29 Sep 2002, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Would it be beneficial for us to extend "pg_config" to update the
> > postgresql.conf file?
>
> This seems far outside pg_config's charter. It is a simple
> information reporter that can be run by anybody. Maki
Tom Lane wrote:
> Marc previously proposed releasing beta3 in about a week --- will that
> be a good time to open HEAD for 7.4 work, or will we need to delay still
> longer? (I'm not sure yet, myself.)
Perhaps it's too early to be able to effectively say when a
real+effective branch is likely t
On Sun, 29 Sep 2002 13:42:43 +0200
Grant Finnemore <[EMAIL PROTECTED]> wrote:
> Note the use of the "RETURN NEXT rec" line in the body
> of the for loop, and also the "RETURN null" at the end.
>
> It is also possible to create typed returns, so in this
> case, in the declare body, the following
Neil Conway <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> OK, personally, I would like to see an actual speedup of PostgreSQL
>> queries before I would apply such a OS-specific, version-specific
>> patch.
> Don't be silly. A performance improvement is a performance
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc, I know we said branch after beta2 but I think we need another week
> or two before we can start using that branch effectively. Even if we
> started using it, like adding PITR, the code would drift so much that
> the double-patching would start to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, personally, I would like to see an actual speedup of PostgreSQL
> queries before I would apply such a OS-specific, version-specific
> patch.
Don't be silly. A performance improvement is a performance
improvement. According to your logic, using assem
Justin Clift <[EMAIL PROTECTED]> writes:
> Would it be beneficial for us to extend "pg_config" to update the
> postgresql.conf file?
This seems far outside pg_config's charter. It is a simple
information reporter that can be run by anybody. Making it able
to mess with (or even look at) postgres
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be because
it implies making a parent inconsistent w
Hannu Krosing <[EMAIL PROTECTED]> writes:
> The initial Postgres design had a notion of StorageManager's, which
> should make this very easy indeed, if it had been kept working .
But the storage manager interface was never built to hide issues like
tuple representation --- storage managers just d
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is TLB Linux-only?
>
> Well, the "TLB" is a feature of the CPU, so no. Many modern processors
> support large TLB pages in some fashion.
>
> However, the specific API for using large TLB pages differs between
> operating syst
Peter Eisentraut wrote:
>
> Justin Clift writes:
>
> > Would it be beneficial for us to extend "pg_config" to update the
> > postgresql.conf file?
>
> That has nothing to do with pg_config's functions.
At present, sure. Was thinking a tool for command line changes of
postgresql.conf parameter
Justin Clift writes:
> Would it be beneficial for us to extend "pg_config" to update the
> postgresql.conf file?
That has nothing to do with pg_config's functions.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscrib
Jim Mercer writes:
> the reasoning for this is that postmaster has no ability to differentiate
> between incoming sessions, and as such, storing the list in the server makes
> no sense, the server won't know how to apply the list.
Right, but libpq also has no concept of what you call "incoming s
Tom Lane kirjutas P, 29.09.2002 kell 04:00:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I have this almost ready. The thing I don't have quite clear yet is
> > what to do with attislocal. IMHO it should not be touched in any case,
> > but Hannu thinks that for symmetry it should be reset in
CREATE OR REPLACE FUNCTION myfunc(integer) RETURNS SETOF record AS '
DECLARE
rec record;
BEGIN
FOR rec IN SELECT * FROM test WHERE a = $1 LOOP
RAISE NOTICE ''a = %, b = %'',rec.a, rec.b;
RETURN NEXT rec;
END LOOP;
RETURN null;
END;
Hi, all
Does 7.3 support "SETOF RECORD" in plpgsql ?
As far as I test it, a function using it in plpgsql always seems to return
no row. On the other hand, a sql function returns correct rows.
If 7.3 doesn't support it in plpgsql, I would think plpgsql needs to raise
an error rather than retur
On Sun, 2002-09-29 at 09:47, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What would that converter need:
> > [snip]
> > I think that should be enough for converting table files. I'd like to
> > experiment with something like this when I have some free time. Maybe
> > next ye
On Sun, 2002-09-29 at 07:19, Lamar Owen wrote:
> On Saturday 28 September 2002 09:23 pm, Bruce Momjian wrote:
> > Justin Clift wrote:
> > > Alvaro Herrera wrote:
> > > > I agree with Lamar that upgrading is a very difficult process right
>
> > > As a "simple for the user approach", would it be
>
Am Samstag, 28. September 2002 10:17 schrieb Shridhar Daithankar:
(snip)
> I have to disagree.. Completely.. This is like turning PG-Metadata into
> registry...
>
> And what happens when index starts splitting when it grows beyond 1GB in
> size?
>
> Putting indexes into a separate subdirectoy and
On 29 Sep 2002 at 0:43, Justin Clift wrote:
> Shridhar Daithankar wrote:
> The reason that I was thinking of having a different path per index
> would be for high volume situations like this:
>
> /dev/dsk1 : /pgdata <- data here
> /dev/dsk2 : /pgindexes1 <- some indexes here
> /dev/dsk3 : /pgind
On 28 Sep 2002 at 12:18, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Shridhar Daithankar wrote:
> >> Looks like we should have a subdirectory in database directory which stores
> >> index.
>
> > That was my first thought also, but an alternative/additional approach
> > would b
44 matches
Mail list logo
