> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 12 September 2002 00:53
> To: Dave Page
> Cc: Oliver Elphick; [EMAIL PROTECTED]
> Subject: Re: [HACKERS]
>
>
> OK, I am going to add these items to the open items list
> because I am having trouble keeping
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other parents and drop it only when it is not
Here is the test case:
hannu=# create table p1(id int,
On Thu, Sep 12, 2002 at 01:56:19PM +0800, Christopher Kings-Lynne wrote:
>
> *sigh*
>
> Well, at least they have an easy and fast upgrade process ;)
Right, fewer pesky features to get in the way of the upgrade ;->
Ross
---(end of broadcast)---
T
MySQL wins Prestigious Linux Journal's Editors' Choice Award:
http://www.mysql.com/news/article-109.html
An amusing quote from the article:
"If you're one of the people who has been saying, 'I can't use MySQL because
it doesn't have [feature you need here]', it's time to read up on MySQL 4.0
an
We dealt this this (painfully) during 7.3 development. Some wanted a -X
flag to initdb/postgres/postmaster that would identify the pg_xlog
directory while others wanted the flag only on initdb and have initdb
create a symlink.
Finally, we decided to do nothing. and continue to recommend manuall
Hi everyone,
Am just wondering if we've ever considered adding a PGXLOG environment
variable that would point to the pg_xlog directory?
In a Unix environment it's not real necessary as filesystem links can be
created, but in other environments (i.e. the Native windows port) it's
looking like it
FYI, SRA, the leading PostgreSQL support company in Japan, has renewed
my employment contract. This will allow me to continue to devote 100%
of my working hours to improving PostgreSQL and assisting them and their
customers. It is a pleasure working for them.
--
Bruce Momjian
FYI, I am going to be away from Thursday night to Sunday on a retreat.
I will be checking my email but may not be able to reply quickly.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive,
Marc G. Fournier wrote:
> On Wed, 11 Sep 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 11 Sep 2002, Bruce Momjian wrote:
> > >
> > > > On Hold
> > > > ---
> > > > Point-in-time recovery
> > > > Win32 port
> > > > Security audit
> > >
> > > Why is the security audit on
On Wednesday 11 September 2002 09:44 pm, Bruce Momjian wrote:
> Lamar Owen wrote:
> > Bruce, I mentioned a sed/perl/awk script already to massage the dump into
> > a 7.3-friendly form -- but we need to gather the cases that are involved.
> > Methinks every single OpenACS installation will hit this
timestamp becoming timestamp without time zone is actually the SQL
standard...
Chris
> I'm sure you all have discussed this ad-nauseum but this sure
> does create a
> pain in the butt when converting.
>
> Ok, I had my say.
>
> Thanks for all your hard work,
>
> L.
> On Wed, 11 Sep 2002, Bruce Mo
At 12:31 PM 9/09/2002 +0100, Oliver Elphick wrote:
> CREATE FUNCTION plperl_call_handler () RETURNS opaque
>^^
> AS '/usr/local/pgsql/lib/plperl.so', 'plperl_call_handler'
> LANGUAGE "C";
...
> CREATE TRUSTED PROCEDUR
On Wed, 11 Sep 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 11 Sep 2002, Bruce Momjian wrote:
> >
> > > On Hold
> > > ---
> > > Point-in-time recovery
> > > Win32 port
> > > Security audit
> >
> > Why is the security audit on hold? This is the best time to do it, while
>
I understand. Thanks for pointing that out.
L.
On Wed, 11 Sep 2002, Bruce Momjian wrote:
>
> I think the SQL standards required the change.
>
> ---
>
> Laurette Cisneros wrote:
> > I'm sure you all have discussed this a
Marc G. Fournier wrote:
> On Wed, 11 Sep 2002, Bruce Momjian wrote:
>
> > On Hold
> > ---
> > Point-in-time recovery
> > Win32 port
> > Security audit
>
> Why is the security audit on hold? This is the best time to do it, while
> the code is reasonably static :(
It is on hold in the sense
Lamar Owen wrote:
> Bruce, I mentioned a sed/perl/awk script already to massage the dump into a
> 7.3-friendly form -- but we need to gather the cases that are involved.
> Methinks every single OpenACS installation will hit this issue.
>
> How big is the problem? It's looking bigger with each
On Wed, 11 Sep 2002, Bruce Momjian wrote:
> On Hold
> ---
> Point-in-time recovery
> Win32 port
> Security audit
Why is the security audit on hold? This is the best time to do it, while
the code is reasonably static :(
---(end of broadcast)
On Wednesday 11 September 2002 05:40 pm, Oliver Elphick wrote:
> On Wed, 2002-09-11 at 21:19, Tom Lane wrote:
> > In the meantime, I think that we shouldn't mess with pg_dump's basically
> > OID-order-driven dump ordering. It works in normal cases, and adding
> > arbitrary rules to it to fix one
Patch applied. Thanks.
---
Teodor Sigaev wrote:
>
>
> > intarray and ltree both seem to be mapping their own declarations onto
> > arrays using largely-similar code. But while intarray fails its
> > regression test, I
Patch applied. Thanks.
---
Joe Conway wrote:
> Tom Lane wrote:
> > Sean Chittenden <[EMAIL PROTECTED]> writes:
> >
> >>::sigh:: Is it me or does it look like all
> >>of pl/pgsql is schema un-aware (ie, all of the declara
At 12:31 PM 9/09/2002 +0100, Oliver Elphick wrote:
>3. A view is being created before one of the tables it refers to.
>Should not views be created only at the very end?
This would be trivial (and we already put several items at the end), but I
am not sure it would fix the problem since views can
Dave Page wrote:
>
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > Sent: 11 September 2002 22:28
> > To: Dave Page
> > Cc: Oliver Elphick; [EMAIL PROTECTED]
> > Subject: Re: [HACKERS]
> >
> >
> > Why can't we do the remapping in the SQL grammar and remo
I think the SQL standards required the change.
---
Laurette Cisneros wrote:
> I'm sure you all have discussed this ad-nauseum but this sure does create a
> pain in the butt when converting.
>
> Ok, I had my say.
>
> Thank
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote:
>
> > I again am not sure I understand, are you saying that under serializable
> > select should start a transaction but it shouldn't under read committed?
> > That seems like a bad idea to me, either
I'm sure you all have discussed this ad-nauseum but this sure does create a
pain in the butt when converting.
Ok, I had my say.
Thanks for all your hard work,
L.
On Wed, 11 Sep 2002, Bruce Momjian wrote:
> Laurette Cisneros wrote:
> >
> > If you define a column as:
> > coltimestamp
> > In
Laurette Cisneros wrote:
>
> If you define a column as:
> coltimestamp
> In 7.2.x didn't it default to timestamp with timezone?
>
> And now in 7.3(b1) it defaults to timestamp without timezone?
/HISTORY says right at the top:
* TIMESTAMP and TIME data types now default to WITHOUT TIME
Oliver Elphick wrote:
> On Wed, 2002-09-11 at 22:27, Bruce Momjian wrote:
> > Dave Page wrote:
> > > > Oh, I thought it was just the permissions that were the
> > > > problem. Can we give them a sed script?
> > >
> > > I guess so. It seems to me that upgrading to 7.3 is going to be the
> > > st
> We can revisit that decision if you like, but you must convince us that
> it was wrong, not just say "of course we should change it".
I am sorry, but at that time I did not have time for the discussion,
and now is also very tight for me :-(
Four reasons I can give:
1. execute xx(...);
On Wed, 2002-09-11 at 22:27, Bruce Momjian wrote:
> Dave Page wrote:
> > > Oh, I thought it was just the permissions that were the
> > > problem. Can we give them a sed script?
> >
> > I guess so. It seems to me that upgrading to 7.3 is going to be the
> > stuff of nightmares, so my first thoug
If you define a column as:
coltimestamp
In 7.2.x didn't it default to timestamp with timezone?
And now in 7.3(b1) it defaults to timestamp without timezone?
Is this right?
--
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
On Wed, 2002-09-11 at 21:19, Tom Lane wrote:
> In the meantime, I think that we shouldn't mess with pg_dump's basically
> OID-order-driven dump ordering. It works in normal cases, and adding
> arbitrary rules to it to fix one corner case is likely to accomplish
> little except breaking other corn
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 11 September 2002 22:28
> To: Dave Page
> Cc: Oliver Elphick; [EMAIL PROTECTED]
> Subject: Re: [HACKERS]
>
>
> Why can't we do the remapping in the SQL grammar and remove
> the remapping in 7.4?
>
I can s
Dave Page wrote:
> > Oh, I thought it was just the permissions that were the
> > problem. Can we give them a sed script?
>
> I guess so. It seems to me that upgrading to 7.3 is going to be the
> stuff of nightmares, so my first thought is to try to avoid getting
> people to run a 7.3 utility on
On Wednesday 11 September 2002 06:11 pm, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > If decision (transaction or not) is after parser (before execute)
> > > > this isn't pr
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 11 September 2002 22:13
> To: Dave Page
> Cc: Oliver Elphick; [EMAIL PROTECTED]
> Subject: Re: [HACKERS]
>
>
> Dave Page wrote:
> > > That's a pretty big hurtle. I think we are better off giving
> > > them
Dave Page wrote:
> > That's a pretty big hurtle. I think we are better off giving
> > them an SQL UPDATE to run.
>
> How would that massage a dump file though? I can't think of any SQL that
> might make 7.2 output 'language_handler' correctly, and we already know
> 7.3 will barf on opaque.
Oh,
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 11 September 2002 17:38
> To: PostgreSQL-development
> Cc: [EMAIL PROTECTED]
> Subject: [HACKERS] New pgaccess
>
>
> I wanted people to see a screen shot of the new pgaccess to
> be releases with 7.3:
>
>
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 11 September 2002 18:21
> To: Oliver Elphick
> Cc: Dave Page; Tom Lane; Lamar Owen; Philip Warner; Laurette
> Cisneros; [EMAIL PROTECTED]
> Subject: Re: [HACKERS]
>
>
> Oliver Elphick wrote:
> > But now we
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Wed, Sep 11, 2002 at 03:42:44PM +0200, Zeugswetter Andreas SB SD wrote:
>> I think it should be the intention to keep those identical, which would
>> mean, that the backend syntax is currently wrong :-(
> Which of course means we should change it. :
Oliver Elphick <[EMAIL PROTECTED]> writes:
> ERROR: Column "year" is of type integer but default expression is
> of type double precision
> You will need to rewrite or cast the expression
>>
>> Hmm ... what was the original coding of the default?
>year INTEGER DEFAULT date_part
yes, deferring views to the end will also break if you have
SQL functions defined that use views. The dependencies
is (are?) a really hard problem.
elein
At 12:41 PM 9/11/02, Jeff Davis wrote:
> > Is it not enough to defer all views until the end? Why would they be
> > needed any sooner?
>
>
Jan Wieck writes:
> I think we will have no chance to really return the number of
> VIEW-tuples affected. So any implementation is only a guess and we could
> simply return fixed 42 if "some" tuples where affected at all. This
> return is as wrong (according to Steve) as everything else but at le
> Is it not enough to defer all views until the end? Why would they be
> needed any sooner?
I would think that views of views, or permissions on views, or prepared
statements might need the right view to be declared first. There may be other
examples as well.
Your solution might be better th
Bruce Momjian writes:
> Is this a TODO?
It's a must-fix for 7.3, but frankly I don't see how we could justify
making the required extensive changes during beta. I suggest that we keep
the parser support and throw an error when it's invoked.
--
Peter Eisentraut [EMAIL PROTECTED]
--
On Wed, Sep 11, 2002 at 03:42:44PM +0200, Zeugswetter Andreas SB SD wrote:
> That is how I understood it so far.
I will dig into this as soon as I find time, i.e. definitely for 7.3.
> > Actually ecpg needs 'execute id using ... into ...'. I did not see any
> > mention of using in the backend ex
Oliver Elphick wrote:
> But now we should be telling people to use 7.3's pg_dumpall, at least
> for 7.2 data. (How far back can it go?)
>
> Make sure you use pg_dumpall from the new 7.3 software to dump
> your data from 7.2. To do this, you must have the 7.2
> postmaster
On Wed, 2002-09-11 at 08:20, Dave Page wrote:
>
>
> > -Original Message-
> > From: Oliver Elphick [mailto:[EMAIL PROTECTED]]
> > Sent: 11 September 2002 07:29
> > To: Tom Lane
> > Cc: Lamar Owen; Bruce Momjian; Philip Warner; Laurette
> > Cisneros; [EMAIL PROTECTED]
> > Subject: Re: [H
I wanted people to see a screen shot of the new pgaccess to be releases
with 7.3:
ftp://candle.pha.pa.us/pub/postgresql/pgaccess.gif
It looks amazing.
The main pgaccess page is:
http://www.pgaccess.org
--
Bruce Momjian| http://candle.pha.pa.us
[EM
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > >
> > > If decision (transaction or not) is after parser (before execute) this
> > > isn't problem.
> > > I don't know when postgresql make decision, but that
On 05 Sep 2002 20:27:23 +0500, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>Has anyone run any speed tests to see how 7.2 and 7.3 compare ?
Running a modified OSDB (CREATE TABLE ... WITHOUT OIDS) with 400 MB
data on a Pentium III 1 GHz, 382 MB RAM, 7200 rpm IBM 14 GB HD under
Linux, this is what I g
On Wed, 2002-09-11 at 14:59, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Let me reiterate. I got these problems dumping 7.2 data with 7.3's
> > pg_dumpall:
>
> > 1. The language handlers were dumped as opaque; that needs to be
> > changed to language_handler.
>
> Okay, we
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Let me reiterate. I got these problems dumping 7.2 data with 7.3's
> pg_dumpall:
> 1. The language handlers were dumped as opaque; that needs to be
> changed to language_handler.
Okay, we need to do something about that, though I'm not sure I see
a
> > I know this is not really related, but wouldn't the plan be to make
> > ecpg actually use the backend side "execute ..." now that it is available ?
>
> Maybe I misunderstood something. Do you mean I could use the backend
> PREPARE/EXECUTE to prepare and execute any statement I can
> PREPARE/
On Wednesday 11 September 2002 02:55 pm, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > > On Wed, 11 Sep 2
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 02:38 pm, Rod Taylor wrote:
> > > > > Why rollback.This is error (typing error).Nothing happen.
> > > > > I think that we need clear set : what is start transaction ?
> > > > > I think that transaction start with change data in da
On Wed, Sep 11, 2002 at 11:23:45AM +0200, Zeugswetter Andreas SB SD wrote:
> I know this is not really related, but wouldn't the plan be to make
> ecpg actually use the backend side "execute ..." now that it is available ?
Maybe I misunderstood something. Do you mean I could use the backend
PREPA
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > >
On Wednesday 11 September 2002 02:38 pm, Rod Taylor wrote:
> > > > Why rollback.This is error (typing error).Nothing happen.
> > > > I think that we need clear set : what is start transaction ?
> > > > I think that transaction start with change data in database
> > > > (what don't change data this
On Wed, 11 Sep 2002, snpe wrote:
> On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > >
On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > yes, we're going around in circles.
> > > >
> > > > Ok.I agreed (I think because Oracle
> > > Why rollback.This is error (typing error).Nothing happen.
> > > I think that we need clear set : what is start transaction ?
> > > I think that transaction start with change data in database
> > > (what don't change data this start not transaction.
> >
> > Another interesting case for a sel
On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > On Wed, 11 Sep 2002, snpe wrote:
> > > > yes, we're going around in circles.
> > > >
> > > > Ok.I agreed (I think because Oracle
On Sun, 8 Sep 2002 19:50:21 -0300, Steve Howe <[EMAIL PROTECTED]>
wrote:
>Proposal #1 (author: Steve Howe):
>-
>
>PQcmdStatus() ==> Should return the last executed command
#1a
> or the same as the original command
#1b = #2
>PQcmdTuples() ==> sho
> Actually there is one more problem. The backend introduced the EXECUTE
> command just recently. However, this clashes with the embedded SQL
> EXECUTE command. Since both may be called just with EXECUTE ,
> there is no way to distinguish them.
>
> I have no idea if there's a standard about exec
On Wed, Sep 11, 2002 at 12:56:59AM -0400, Alvaro Herrera wrote:
> Just for the record: bison 1.49b reports lots of "invalid character"
> when processing plpgsql's grammar. However, the regression test passes.
> This is Linux/i686.
>
> $ make gram.c -C src/pl/plpgsql/src
> make: Entering director
On Wed, Sep 11, 2002 at 12:45:06AM -0400, Tom Lane wrote:
> No? If there are bugs in it, they will break the main SQL parser, not
> only ecpg. I am scared.
Actually there is one more problem. The backend introduced the EXECUTE
command just recently. However, this clashes with the embedded SQL
E
Curt Sampson wrote:
> On Wed, 11 Sep 2002, Mark Kirkwood wrote:
>
>
>
> Hm, it appears we've both been working on something similar. However,
> I've just released version 0.2 of randread, which has the following
> features:
>
funny how often that happens...( I think its often worth the effor
AMD Athlon 500
512MB Ram
IBM 120GB IDE
Tested with:
BLCKSZ=8192
TESTCYCLES=50
Result:
Collecting sizing information ...
Running random access timing test ...
Running sequential access timing test ...
Running null loop timing test ...
random test: 2541
sequential test: 2455
null timin
68 matches
Mail list logo
