"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> What kinda processor are you running?
>From dmesg:
Timecounter "i8254" frequency 1193182 Hz
CPU: Intel Celeron (631.29-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x383f9ff
-Neil
--
On Fri, 28 Nov 2003, Neil Conway wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Fri, 28 Nov 2003, Neil Conway wrote:
> >> $ uname -a
> >> FreeBSD home.samurai.com 4.9-RELEASE [...]
> >
> > what is kern.timecounter.method set to?
>
> $ sysctl kern.timecounter.method
> kern.timecount
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Neil Conway wrote:
>> $ uname -a
>> FreeBSD home.samurai.com 4.9-RELEASE [...]
>
> what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI, I ran the test program for another 30
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5 --with-includes=/usr/ke
On Fri, 28 Nov 2003, Neil Conway wrote:
> $ uname -a
> FreeBSD home.samurai.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Thu Nov 6 21:25:41 EST
> 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAMURAI i386
>
> This machine produces no output after running the test app for about
> 30 minutes.
what
Joe Conway <[EMAIL PROTECTED]> writes:
> As of this change:
> http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
> I can't seem to configure --with-krb5.
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5 --with-includes=/usr/kerberos/in
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> 15 minutes of error is acceptable?
> Apparently *shrug* That was just the first answer back though, so we'll
> see what happens ...
BTW, it seems from this thread that the BIND guys have seen even more
bogus behavior than this from gettimeofday()
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Just got my first response on this, and, in fact, this is 'acceptable
> > behaviour' to a certain extent ... there is a kernel tuneable called
> > kern.timecounter.method, that is either 1 or 0:
>
> 15 minute
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
The configure script I've used (derived from what the the RH9 RPM spec
file does) for quite some time now is:
./configure \
--host=i386-redhat-linux \
--build=i386-redh
On Fri, 28 Nov 2003, Marc G. Fournier wrote:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > I'm suspecting that the issue is amplified by load on the server itself
> >
> > That would fit right in with my idea that the failure occurs when the
> > p
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Just got my first response on this, and, in fact, this is 'acceptable
> behaviour' to a certain extent ... there is a kernel tuneable called
> kern.timecounter.method, that is either 1 or 0:
15 minutes of error is acceptable?
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
>
> > $ time ./a.out 2>&1 | tee a.txt
> > out of order tv_sec: 1070066197 273140, prev 1070066195 721010
> > out of order tv_usec: 1070066197 273140, prev 1070066195 721010
> > out of order tv_sec: 1070067322 11
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm suspecting that the issue is amplified by load on the server itself
>
> That would fit right in with my idea that the failure occurs when the
> process loses its timeslice partway through gettimeofday().
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its timeslice partway through gettimeofday(). Heavier
load would presumably make it more lik
On Fri, 28 Nov 2003, Tom Lane wrote:
> Could it be a hardware problem on Marc's box? Or specific to some other
> aspect of that installation (Marc, is pgsql74.hub.org multi-CPU, for
> example?)
All the servers are SMP ... pgsql74 is on a Dual-Xeon ...
Marc G. Fournier Hub.Org Net
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> Ah, I have made a mistake. It's only a 2.2.18 kernal. Dual SMP P-III, perhaps
> that's the issue there.
Hm. I seem to recall there were still lots of SMP bugs in the 2.2.*
kernels.
> And on the FreeBSD system I've got this:
> $ time ./a.out 2>&1
On Fri, 28 Nov 2003, Darcy Buskermolen wrote:
> I've been running this code on a pair of FreeBSD (i386) boxen, for some time
> now, one of which is a 4.8-STABLE, the other is a 5.2-BETA.
>
> In 10 minutes of execution the 4.8 box has only shown the following:
>
> out of order tv_sec: 1070063393 11
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > On Fri, 28 Nov 2003, Tom Lane wrote:
> >> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> > are all just a microsecond.
> >>
> >> W
Tom Lane <[EMAIL PROTECTED]> writes:
> Whoa. Try the following test program.
I tried this on two uniprocessor x86 machines:
(1)
$ uname -a
Linux tokyo 2.6.0-test10 #3 Mon Nov 24 13:43:54 EST 2003 i686 GNU/Linux
This machine produces this output, after running the test app for
about 30 minutes:
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> are all just a microsecond.
>>
>> What do you mean by "just a microsecond"?
> I mean i
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> After 30+ minutes I'm now starting to see the same problems on my 5.2 testbed
> as well. I'm going to fire this test up on my FreeBSD 3.x and 2.x boxen and
> see if' it's there too. I can confirm that this not a SMP issue as that it's
> happeing on
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> > are all just a microsecond.
>
> What do you mean by "just a microsecond"?
I mean it's always a "out of order tv_usec..." line and t
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45", but they
> are all just a microsecond.
What do you mean by "just a microsecond"?
Attached is a tightened-up test program that will only complain if the
value of gettimeofday goes backwar
On November 28, 2003 04:19 pm, Tom Lane wrote:
> I said:
> > The failure is definitely quite repeatable on pgsql74.hub.org. I don't
> > see it on svr1.postgresql.org, though, which seems to be running almost
> > the same kernel.
>
> After looking more closely, I take that back: svr1 is failing too
On Fri, 28 Nov 2003, Tom Lane wrote:
> Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > On November 28, 2003 12:33 pm, Tom Lane wrote:
> >> Whoa. Try the following test program. Then send it in to your friendly
> >> local BSD hackers
>
> > I've been running this code on a pair of FreeBSD
On November 28, 2003 12:33 pm, Tom Lane wrote:
> I said:
> > I'm wondering if there's an actual bug in gettimeofday() in this
> > platform, such that once in a while it returns a value that's off
> > a minute or so ...
>
> Whoa. Try the following test program. Then send it in to your friendly
> l
I said:
> The failure is definitely quite repeatable on pgsql74.hub.org. I don't
> see it on svr1.postgresql.org, though, which seems to be running almost
> the same kernel.
After looking more closely, I take that back: svr1 is failing too,
though not as often:
> uname -a
FreeBSD svr1.postgresql
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> On November 28, 2003 12:33 pm, Tom Lane wrote:
>> Whoa. Try the following test program. Then send it in to your friendly
>> local BSD hackers
> I've been running this code on a pair of FreeBSD (i386) boxen, for some time
> now, one of which i
On November 28, 2003 12:33 pm, Tom Lane wrote:
> I said:
> > I'm wondering if there's an actual bug in gettimeofday() in this
> > platform, such that once in a while it returns a value that's off
> > a minute or so ...
>
> Whoa. Try the following test program. Then send it in to your friendly
> l
Gavin Sherry <[EMAIL PROTECTED]> writes:
> What to do? Well, as far as I can tell, there are no work arounds
This was discussed a few months ago and set aside because no one had a
really decent solution at the time.
The behavior is not really all that different from the discontinuities
that occur
On Wed, 25 Nov 2003, Paul Tuckfield wrote:
> I really like the idea of taking a snapshot backup with postgres, using
> either volume manager or hardware splits in a disk array to get a
> physical backup.
Does anyone else see any value in snapshotting. It would, I image,
essentially work like this
On Thu, 27 Nov 2003, Mike Macaskill wrote:
> Linux 2.4.20, PG 7.3.2 (this is the box where we wish to run our
> application)
> HP-UX 11.11, PG 7.3.2, 7.3.4, 7.4 (this is just a test box where PG
> installs take less time)
>
> On all of these configurations the the date '1901/12/14' apparently doe
On Wed, Nov 26, 2003 at 05:34:28PM +0100, Hans-Jürgen Schönig wrote:
> The reason why I came up with this posting is slightly different: Assume
> a JDBC application which works with PostgreSQL + some other database. If
> you want to use both databases without PostgreSQL being unnecessarily
> sl
Ollie Clark writes:
> Since upgrading to 7.3 I've noticed that the ORDER BY clause seems to
> ignore leading spaces/punctuation for eg we have a simple table with 6
> rows containing:
You need to set the right locale. You appear to expect the "C" locale, so
you need to tell initdb about it.
--
did you happen to take a look at the other set of queries I sent you, that
were showing 39k and 41k explain results? do they show pretty much the
same 'lag' in gettimeofday()?
On Fri, 28 Nov 2003, Tom Lane wrote:
> > ... if its just me mis-reading the numbers, let me
> > know ... it just "feels
Paul Tuckfield wrote:
> I really like the idea of taking a snapshot backup with postgres, using
> either volume manager or hardware splits in a disk array to get a
> physical backup.
>
> In other, lesser database systems :) the system is structured to prevent
> problems arising from "split block"
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> did you happen to take a look at the other set of queries I sent you, that
> were showing 39k and 41k explain results?
You mean this one?
> time psql -c "explain analyze select max(intag) from ndict3" 186_archives
Tom, I am afraid that I don't understand. My first example:
wow=# explain analyze select max(click.accesses) from click;
QUERY PLAN
-
A
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > did you happen to take a look at the other set of queries I sent you, that
> > were showing 39k and 41k explain results?
>
> You mean this one?
Yup ...
> > time psql -c "explain analyze select max(intag) fr
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Tom, I am afraid that I don't understand. My first example:
> wow=# explain analyze select max(click.accesses) from click;
> QUERY PLAN
> -
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>> Now that I recall, didn't you complain of something similar with a beta?
> Yup ... and I bet its not reproducible yet again, is it? :) That would
> make for twice though, with v7.4, that I've come up with - r
On Thu, 27 Nov 2003, Rod Taylor wrote:
> On Thu, 2003-11-27 at 00:50, Marc G. Fournier wrote:
> > Based on discussions on -hackers, and baring any objections betwen now and
> > then, I'm going to go through all files in CVS and change:
> >
> > $Id$ -> $PostgreSQL$
> >
> > I will do this the ev
I said:
> I'm wondering if there's an actual bug in gettimeofday() in this
> platform, such that once in a while it returns a value that's off
> a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
> uname -a
FreeBSD pgsql74.hub.org 4.
None that I've heard of ... Sean?
Tom, any way of writing a quite test C program for this? Something to
'simulate' the same thing, but without having to build the whole
postmaster?
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Fri, 28 Nov 2003, To
> k, there was no options file already, so I just added it containing the
> one line ...
>
> And tested in on GNUMakefile.in, and appears okay:
>
> #
> # $PostgreSQL: pgsql-server/GNUmakefile.in,v 1.36 2003/11/28 20:32:09 pgsql Exp $
> #
Looks good. Once you are comfortable with the changes, you
On Fri, 28 Nov 2003, Rod Taylor wrote:
> > k, there was no options file already, so I just added it containing the
> > one line ...
> >
> > And tested in on GNUMakefile.in, and appears okay:
> >
> > #
> > # $PostgreSQL: pgsql-server/GNUmakefile.in,v 1.36 2003/11/28 20:32:09 pgsql Exp $
> > #
>
> L
> > Looks good. Once you are comfortable with the changes, you will need to
> > add another line to CVSROOT/options to disable processing of the $Id$
> > and $Header$ tags should one accidentally be added.
> >
> > tagexpand=iPostgreSQL
>
> 'K, where do you find docs on the options file? t
Since upgrading to 7.3 I've noticed that the ORDER BY clause seems to
ignore leading spaces/punctuation for eg we have a simple table with 6
rows containing:
'a'
'b'
'c'
'd'
' bill'
'-bill'
SELECT * FROM table ORDER BY 1;
gives:
a
b
bill
-bill
c
d
which is different from previous versions a
> I get the feeling that what we will see is the destination
> filename already present and the source not, which would suggest
> that two backends tried to do the rename concurrently.
Tom,
I just noticed that the rename panic errors like this one:
PANIC: rename from /data/pg_xlog/00030
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
Recently I have come across a simple issue which made me think about it.
When we create a tmp table (SELECT INTO, CREATE TABLE AS) the planner
won't know anything about its content after creating it.
Run ANALYZ
>> Today I've d-loaded PostgreSQL 7.3.4.
>> I've seen in
>> $PGSQLD/doc/html/index.html
>> it still says
>> Copyright (C) 1996-2002
>> shouldn't it be 2003?
>
> We only update the copyright notices when we are preparing a major
> release. (Bruce just did it a week or two back for 7.4, for example
>> > They stopped at 7.2.4 because "they're finishing some usefull APIs,
>> > which'll make the port much more "easy"."
>>
>> Will this involve using a Linux kernel ;)
>
> :) No, a NW kernel with a POSIX library. This'll be great, because
> :you'll can run powerfull opensource software with an ent
Title: Message
Hi
We are attempting to
setup a database application on a Linux box, but we are
having
problems loading
data with particular dates.
My colleague, Arnold
Mavromatis has already made postings to the pgsql-bugs list,
but we are still no
closer to having the bug fixed, so I t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 26 November 2003 09:19, Hannu Krosing wrote:
>
> First, You could start by implementing materialized views manually,
> using tables and triggers, to get the feel of what should be generated.
>
> Next, still working from frontend, try to ma
On Fri, 21 Nov 2003, Matthew T. O'Connor wrote:
> >> Do you know of an easy way to get a
> >>count of the total pages used by a whole cluster?
> >
> >Select sum(relpages) from pg_class.
You might want to exclude indexes from this calculation. Some large
read only tables might have indexes larger t
We're looking at storing the equivalent of very large rasters images
in
postgres. Our understanding is that postgres stores large objects
as little pieces in rows of a table. As our images would be 30MB-4GB
in size, this would be a lot of rows. Has anybody used a different
mechanism to store their
Here's a slightly condensed version - do SQL functions have an advantage in
that they can be inlined? Or have I misunderstood?
CREATE OR REPLACE FUNCTION user_in_group(name,name) RETURNS boolean STRICT
AS '
SELECT EXISTS(SELECT u.* FROM pg_catalog.pg_user u INNER JOIN
pg_catalog.pg_group g ON (u.
[EMAIL PROTECTED] (Christopher Kings-Lynne) wrote in message news:<[EMAIL
PROTECTED]>...
> Lastly, I presume it's possible to create a system of circular
> dependencies (eg create or replace view), which really cannot be solved
> without a system of 'shells', similar to that needed to dump types
We had this discussion. information_schema doesn't deliver enough info
needed for admin tools.
It should. This is the sole reason for existance of it. If it is not
enough, then it should be updated.
It can't. ANSI says only objects owned by the user are shown. Admins
might be quite unha
Andreas Pflug kirjutas N, 20.11.2003 kell 16:10:
> Hannu Krosing wrote:
>
> >
> >
> >You are just shifting the interface problems to a place needing way more
> >changes in the backend. There will be some problems either way.
> >
> >
> Not quite. Certainly, basing internal storage on attstoragenu
Just a thought. You could also run the regression test automatically after a
successful build?
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> Jean-Michel POURE wrote:
>
> >Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
> >
> >
> >>I think the main value
Dave,
I know that the backend does - it is an essential feature.
Clustered JDBC parses the statement sent to it in order to find out what
to do with it. I have played around a little (mostly interactive shell).
You will find out that Clustered JDBC will complain in this case because
it doesn't
I really like the idea of taking a snapshot backup with postgres, using
either volume manager or hardware splits in a disk array to get a
physical backup.
In other, lesser database systems :) the system is structured to prevent
problems arising from "split block" writes, meaning that though the
da
Peter Eisentraut wrote:
Hans-Jürgen Schönig writes:
Especially the disaster recovery mechanism and things such as adding new
masters need some more work.
Yes, someone is working on automatic recovery (which would extend to
adding new masters by starting recovery from zero). In fact, they're ju
> ... if its just me mis-reading the numbers, let me
> know ... it just "feels" off
Here's what I see:
> time psql -c "explain analyze SELECT count(rec_id) FROM url" 186_archives
QUERY PLAN
--
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> You can do any amount of processing you want in an INSERT statement,
>> though.
> Certainly, but for bulk loads that requires more pre-processing work for
> the user and I believe results in more work for the serv
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> How many times is gettimeofday called?
Twice per plan node visit, if you are doing EXPLAIN ANALYZE. (The
number of "visits" is one more than the number of rows returned.)
regards, tom lane
---(end of bro
How many times is gettimeofday called?
wow=# explain analyze select 1;
QUERY PLAN
Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.008..0.010 rows=1 loops=1)
Total ru
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > No, I'm interested, as I discussed in my message[1], in the ability to
> > use functions in a copy statement to allow me to specify the conversion
> > from text to the appropriate data type.
>
> COPY is not inten
On Fri, 28 Nov 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Actually, I'm noticing similar "problems" with v7.4 ... "EXPLAIN ANALYZE"
> > seems to be showing some *very* high ms for execution time, but if you run
> > the actual query, it doesn't seem to take even 1/10
Stephen Frost <[EMAIL PROTECTED]> writes:
> No, I'm interested, as I discussed in my message[1], in the ability to
> use functions in a copy statement to allow me to specify the conversion
> from text to the appropriate data type.
COPY is not intended to be that flexible; it's intended to be fast.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
> So I suggest that we change back to -fpic until we get detailed evidence.
Okay with me. It never struck me that we'd really seen adequate
evidence that -fPIC was needed.
Makef
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I guess my example was lacking, I'm sure there are cases where the
> > text->date casting will end up being wrong or some date style won't be
> > accepted. If the above was 'January 10th, 2003, October 1st, 2003,
Stephen Frost <[EMAIL PROTECTED]> writes:
> I guess my example was lacking, I'm sure there are cases where the
> text->date casting will end up being wrong or some date style won't be
> accepted. If the above was 'January 10th, 2003, October 1st, 2003,
> January 1st, 2003', for example. Thinking
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Actually, I'm noticing similar "problems" with v7.4 ... "EXPLAIN ANALYZE"
> seems to be showing some *very* high ms for execution time, but if you run
> the actual query, it doesn't seem to take even 1/10th the time reported
> ...
Example? I don't
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Consider the following input data:
> > 1234,24.50,10-Jan-2003,10/1/03,10-01-2003,hiall
>
> > The interpretation for the numbers is:
> > 1234 =3D 12.34, 24.50 =3D 24.50
> > The interpretation for the dat
On Fri, 28 Nov 2003, Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Explain analyze takes 3 times more time for execution. Why?
>
> Measurement overhead. It would seem your platform has a particularly
> slow version of gettimeofday() though ... I've never noticed such a
> large d
"E.Rodichev" <[EMAIL PROTECTED]> writes:
> /e:2>createdb test
> test | er | SQL_ASCII <- Incorrect!
> (3 rows)
> Let's note than the last line is in fact completely incorrect.
What's incorrect about it? You didn't ask for any other encoding
than SQL_ASCII.
You can set the def
Stephen Frost <[EMAIL PROTECTED]> writes:
> Consider the following input data:
> 1234,24.50,10-Jan-2003,10/1/03,10-01-2003,hiall
> The interpretation for the numbers is:
> 1234 =3D 12.34, 24.50 =3D 24.50
> The interpretation for the dates is:
> January 10th, 2003, October 1st, 2003, Oc
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Explain analyze takes 3 times more time for execution. Why?
Measurement overhead. It would seem your platform has a particularly
slow version of gettimeofday() though ... I've never noticed such a
large discrepancy myself.
regar
Karel Zak <[EMAIL PROTECTED]> writes:
> On Thu, Nov 27, 2003 at 09:49:22AM +0100, Nhan NGO DINH wrote:
>> This output has been obtained from a PostgreSQL 7.3.4
> I think it's fixed in 7.4.
Yes. The patch will also be in 7.3.5 when we release that (probably in
the next week or so).
Oli Sennhauser wrote:
People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made before.
I'm simply presenti
On Fri, Nov 28, 2003 at 02:35:11PM +0100, Peter Eisentraut wrote:
> Karel Zak writes:
>
> > in our TODO is the item: "Add PL/PgSQL packages".
>
> I think the interesting part are the package-global variables. The
> name hierarchy seems completely redundant with schemas.
Agree, but there is m
Karel Zak writes:
> in our TODO is the item: "Add PL/PgSQL packages".
I think the interesting part are the package-global variables. The
name hierarchy seems completely redundant with schemas.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)
Hi,
in our TODO is the item: "Add PL/PgSQL packages".
I thought about it and for example Oracle's CREATE PACKAGE / PACKAGE
BODY seems really interesting and modular. IMHO it's interesting item
in PostgreSQL TODO, but I think there a is small collision between the
schemas and possibl
Late in the 7.4 release we've added a patch that changed -fpic to -fPIC
for Linux Sparc. We wanted to investigate that issue further later on.
I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
So I suggest that we change back to -fpic until we get detailed evidence.
Any oth
People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made before.
I'm simply presenting a problem for which
87 matches
Mail list logo
