> -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: [HACKERS]
>
>
> Let me reiterate. I got these problems dumping 7
On Wed, 11 Sep 2002, Mark Kirkwood wrote:
> Yes...and at the risk of being accused of marketing ;-) , that is
> exactly what the 3 programs in my archive do (see previous post for url) :
Hm, it appears we've both been working on something similar. However,
I've just released version 0.2 of randr
On Wed, 2002-09-11 at 05:20, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > On Tuesday 10 September 2002 11:43 pm, Tom Lane wrote:
> >> AFAIK, we did what we could on that front in 7.2.1. If you have ideas
> >> on how we can retroactively make things better, I'm all ears ...
>
> >
Tom Lane wrote:
> Perhaps it's time to remind people that what we want to measure
> is the performance seen by a C program issuing write() and read()
>commands, transferring 8K at a time, on a regular Unix filesystem
Yes...and at the risk of being accused of marketing ;-) , that is
exactly what
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We will not find out if there are problems with the bison beta until we
> > ship it as part of beta and I don't think we have to be scared of just
> > because it is beta.
>
> No? If there are bugs in it, they will break the main SQL
Bruce Momjian wrote:
> Tom Lane wrote:
>>That sounds like massive overkill. Just apply the patch. We don't need
>>to institutionalize a regression test for this.
>
> It would catch people who don't apply the patch. We could remove the
> test after 7.3. Just an idea.
>
The existing strings r
Tom Lane dijo:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We will not find out if there are problems with the bison beta until we
> > ship it as part of beta and I don't think we have to be scared of just
> > because it is beta.
>
> No? If there are bugs in it, they will break the main SQ
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 10, 2002 9:10 PM
> To: Michael Meskes
> Cc: PostgreSQL Hacker; Marc G. Fournier
> Subject: Re: [HACKERS] 7.3beta and ecpg
>
>
>
> I think we should stop playing around with ecpg. Let's get
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We will not find out if there are problems with the bison beta until we
> ship it as part of beta and I don't think we have to be scared of just
> because it is beta.
No? If there are bugs in it, they will break the main SQL parser, not
only ecpg. I a
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am not either. How do you do the documentation when the function can
> > be called two ways.
>
> You don't. There is only one supported name, so that's the only one
> you document.
>
> > I guess we can give the SQL query to fix
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am not either. How do you do the documentation when the function can
> be called two ways.
You don't. There is only one supported name, so that's the only one
you document.
> I guess we can give the SQL query to fix it during
> beta2 _and_ add a re
Here are the open items:
P O S T G R E S Q L
7 . 3 O P E NI T E M S
Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
Source Code Changes
---
Schema handling - ready? interfaces? client apps?
Drop column h
Hackers,
Is there some documentation on TOAST? In the SGML docs there isn't even
a description of it, and in the release notes I cannot find anything but
very light mentions. I've seen descriptions scattered around the web
while Googling, but they are very light and don't seem "official".
Any
Is this a TODO?
---
Peter Eisentraut wrote:
> Thomas Lockhart writes:
>
> > > SIMILAR TO doesn't implement the SQL standard, it's only a wrapper around
> > > the POSIX regexp matching, which is wrong. I thought someone wa
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Tuesday 10 September 2002 11:43 pm, Tom Lane wrote:
>> AFAIK, we did what we could on that front in 7.2.1. If you have ideas
>> on how we can retroactively make things better, I'm all ears ...
> So this release is going to be the royal pain release to
Dann Corbit wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 10, 2002 9:10 PM
> > To: Michael Meskes
> > Cc: PostgreSQL Hacker; Marc G. Fournier
> > Subject: Re: [HACKERS] 7.3beta and ecpg
> >
> >
> >
> > I think we should st
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Teodor Sigaev wrote:
>
>
> > intarray and lt
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Joe Conway wrote:
> Tom Lane wrote:
> > Sean C
I think we should stop playing around with ecpg. Let's get the beta
bison on postgresql.org and package the proper ecpg version for
7.3beta2. If we don't, we are going to get zero testing for 7.3 final.
Marc?
We will not find out if there are problems with the bison beta until we
ship it as p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What do people think if this change?
>
> I'm not thrilled about renaming the function without forcing an initdb
> ... but the alternatives seem worse. Okay by me if we do it.
I am not either. How do you do the documentation when t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do people think if this change?
I'm not thrilled about renaming the function without forcing an initdb
... but the alternatives seem worse. Okay by me if we do it.
regards, tom lane
---(end of broa
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yep, and he couldn't reproduce it either, and on a different platform.
> I think that indicates we do have a problem in there, it just doesn't
> show very often.
I agree, this looks a lot like a low-probability bug. But how to attack
it when we can't
On Tuesday 10 September 2002 11:43 pm, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > However, there is a problem in that recent changes have made it quite
> > likely that an upgrade will fail and will requre the dump script to be
> > edited. There are some issues in pg_dump / p
Oliver Elphick <[EMAIL PROTECTED]> writes:
> However, there is a problem in that recent changes have made it quite
> likely that an upgrade will fail and will requre the dump script to be
> edited. There are some issues in pg_dump / pg_dumpall that need
> addressing before final release.
AFAIK,
Christopher Kings-Lynne wrote:
> I think it should be made. Don't force an initdb. Beta testers can run the
> update. 'split' is a pretty standard function these days...
>
Me too. Patch already sent in, including doc and regression test.
And as I said, I'll take a TODO to create a 'split' wh
On Tue, 10 Sep 2002, Barry Lind wrote:
> Yes I can check the server version on connect. In fact that is what the
> driver already does. However I can't check the version and then based
> on the version call set autocommit true in one round trip to the server.
> Since many people don't use c
I think it should be made. Don't force an initdb. Beta testers can run the
update. 'split' is a pretty standard function these days...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Wednesday, 11 September 2002 10:33
Curt,
Yes I can check the server version on connect. In fact that is what the
driver already does. However I can't check the version and then based
on the version call set autocommit true in one round trip to the server.
Since many people don't use connection pools, I am reluctant to add
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 do different)
> > > Transaction start
> > > I type invalid command
> > >
Yep, and he couldn't reproduce it either, and on a different platform.
I think that indicates we do have a problem in there, it just doesn't
show very often. He even got ASCII garbage in the error message.
---
Rod Taylor
Rod, are you still seeing this failure?
---
Rod Taylor wrote:
> On Wed, 2002-09-04 at 22:39, Marc G. Fournier wrote:
> >
> > will announce it on -announce tomorrow, if ppl want to take a quick look
> > at it ... man pages
What do people think if this change?
---
Hannu Krosing wrote:
>
> It seems that my last mail on this did not get through to the list ;(
>
>
>
> Please consider renaming the new builtin function
>
> split(text,text,i
On Tue, 10 Sep 2002, Lamar Owen wrote:
> I still remember when the Alpha port _required_ -O0. And it was documented
> that way, IIRC.
Good. It would also be very nice if, in situations like this, the
configure script could detect this and use -O0 when compiling on
the alpha.
> Compiling from s
On Tue, 2002-09-10 at 21:44, Curt Sampson wrote:
> But there were some issues with rolling back and SET commands,
> weren't there? I remember a long discussion about this that I'm
> not sure I want to go back to. :-)
So.. Unless explicitly requested, a SET command should have immediate
effect?
Curt Sampson wrote:
> On Tue, 10 Sep 2002, Bruce Momjian wrote:
>
> > Do we want to say "With autocommit off, SET will be in it's own
> > transaction if it appears before any non-SET command", and "SETs are
> > rolled back except if autocommit off and they appear before any
> > non-SET"?
>
> Not
On Tuesday 10 September 2002 09:31 pm, Curt Sampson wrote:
> On Wed, 11 Sep 2002, Peter Eisentraut wrote:
> > I disagree. Choosing the compiler options is exactly the job of the
> > installer, packager, or distributor.
> If there is one, yes.
If the enduser is directly compiling the source, the
On Tue, 10 Sep 2002, Bruce Momjian wrote:
> Do we want to say "With autocommit off, SET will be in it's own
> transaction if it appears before any non-SET command", and "SETs are
> rolled back except if autocommit off and they appear before any
> non-SET"?
Not really, I don't think.
But I'm sta
On Tue, 10 Sep 2002, Barry Lind wrote:
> I am waiting for this thread to conclude before deciding exactly what to
> do for the jdbc driver for 7.3. While using the 'set autocommit true'
> syntax is nice when talking to a 7.3 server, the jdbc driver also needs
> to be backwardly compatible with 7
On Tue, 10 Sep 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Well, for the sequential reads, the readahead should be trigerred
> > even when reading from a raw device.
>
> That strikes me as an unportable assumption.
Not only unportable: but false. :-) NetBSD, at least, do
On Tue, 10 Sep 2002, Tom Lane wrote:
> As of CVS tip, SET commands *do* initiate transactions
> if you have autocommit off. By your reading of Date, this is not
> spec compliant for certain SET variables: a SET not already within
> a transaction should not start a transaction block, at least for
On Wed, 11 Sep 2002, Peter Eisentraut wrote:
> I disagree. Choosing the compiler options is exactly the job of the
> installer, packager, or distributor.
If there is one, yes.
> I don't think we're doing anyone a service if we spread wild speculations
> about how risky certain compiler options
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 do different)
> > > Transaction start
> > > I type invalid command
> > >
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 do different)
> > Transaction start
> > I type invalid command
> > I correct command
> > I get error
> >
> > Why.If i
On Wed, 11 Sep 2002, snpe wrote:
> yes, we're going around in circles.
>
> Ok.I agreed (I think because Oracle do different)
> Transaction start
> I type invalid command
> I correct command
> I get error
>
> Why.If is it transactin, why I get error
> I want continue.
> I am see this error with JD
On Wednesday 11 September 2002 01:25 am, Stephan Szabo wrote:
> On Wed, 11 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> > > On Tue, 10 Sep 2002, snpe wrote:
> > > > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > > > What if it's a selec
On Wed, 11 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> > On Tue, 10 Sep 2002, snpe wrote:
> > > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > > What if it's a select for update? IF that failed because of a timout
> > > > on a lock, sh
On Tuesday 10 September 2002 11:50 pm, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > > What if it's a select for update? IF that failed because of a timout
> > > on a lock, shouldn't the transaction fail? Or a select i
Neil Conway writes:
> Also, if -O3 *is* a good compiler option, I dislike the idea of
> enabling it for your own packages but no one else's. IMHO distributors
> should not futz with packages more than is strictely necessary, and a
> change like this seems both unwarranted, and potentially dangero
Sean Chittenden writes:
> Hrm, I should go check the archives, but I thought what was used was
> one step below -C[fF] and was used because of size concerns for
> embedded databases. My memory for what happens on mailing lists seems
> to be fading though so I'll look it up.
The particular decis
Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Jan Wieck wrote:
> > > We should surely keep this on a much more technical level and avoid any
> > > personal offendings. To do so, please explain to me why you think that
> > > triggers and constraints are out of focus here? What is the difference
On Tue, 2002-09-10 at 23:09, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > edited. There are some issues in pg_dump / pg_dumpall that need
> > addressing before final release.
>
> OK, can you specifically list them?
Message yesterday to pgsql-hackers
Subject: [HACKERS] pg_dump probl
Oliver Elphick wrote:
> On Tue, 2002-09-10 at 18:38, Bruce Momjian wrote:
> >
> > I am confused. This wording seems fine to me.
>
> The confusion was mine. Of course, pg_dump doesn't create the
> database. I was mixing it up with pg_dumpall.
>
> However, there is a problem in that recent cha
On Tue, 2002-09-10 at 18:38, Bruce Momjian wrote:
>
> I am confused. This wording seems fine to me.
The confusion was mine. Of course, pg_dump doesn't create the
database. I was mixing it up with pg_dumpall.
However, there is a problem in that recent changes have made it quite
likely that an
On Tue, 10 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > What if it's a select for update? IF that failed because of a timout on a
> > lock, shouldn't the transaction fail? Or a select into? Either of those
> > should make a transaction fail, and they
Bruce Momjian wrote:
>
> Jan Wieck wrote:
> > We should surely keep this on a much more technical level and avoid any
> > personal offendings. To do so, please explain to me why you think that
> > triggers and constraints are out of focus here? What is the difference
> > between a trigger, a rule
> -Original Message-
> From: Michael Meskes [mailto:[EMAIL PROTECTED]]
> Sent: 10 September 2002 20:42
> To: PostgreSQL Interfaces; PostgreSQL Hacker
> Subject: [HACKERS] ODBC problem/question
>
>
> Hi,
>
> I was just contacted by a customer about the
> SQLProcedureColumns call in o
On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > > It starts a transaction, failes the first command and goes into
> > > > > > the error has occurred in this transaction state. Seems like
> > > > > > reasonable behavior.
> > > > >
>
On Tuesday 10 September 2002 09:55 pm, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That seems messy. What you are saying is that if autocommit is off,
> > then in:
> >
> > SET x=1;
> > UPDATE ...
> > SET y=2;
> > ROLLBACK;
> >
> > that the x=1 doesn't get rolle
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That seems messy. What you are saying is that if autocommit is off,
> > then in:
>
> > SET x=1;
> > UPDATE ...
> > SET y=2;
> > ROLLBACK;
>
> > that the x=1 doesn't get rolled back bu the y=2 does?
>
> Yes, if you
On Tue, 10 Sep 2002, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, scott.marlowe wrote:
>
> > On Tue, 10 Sep 2002, Stephan Szabo wrote:
> >
> > > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > > error has occurred in this transaction state. Seems like reas
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That seems messy. What you are saying is that if autocommit is off,
> then in:
> SET x=1;
> UPDATE ...
> SET y=2;
> ROLLBACK;
> that the x=1 doesn't get rolled back bu the y=2 does?
Yes, if you weren't in a transaction at the
Hi,
I was just contacted by a customer about the SQLProcedureColumns call in
our odbc driver. It appears this call is undefined in the standard odbc
driver but is available in odbcplus. Could anyone please enlighten me
why this was forked and not merged into one driver? Is there a problem
when I
On Tue, 10 Sep 2002, scott.marlowe wrote:
> On Tue, 10 Sep 2002, Stephan Szabo wrote:
>
> > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > error has occurred in this transaction state. Seems like reasonable
> > > > > > behavior.
> > > > >
> > > > > Select
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Does anyone see any cases where it's important for SET to start
> >> a transaction? (Of course, if you are already *in* a transaction,
> >> the SET will be part of that transaction. The question is whether
> >>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Does anyone see any cases where it's important for SET to start
>> a transaction? (Of course, if you are already *in* a transaction,
>> the SET will be part of that transaction. The question is whether
>> we want SET to trigger an im
On Tue, 10 Sep 2002, Stephan Szabo wrote:
> > > > > It starts a transaction, failes the first command and goes into the
> > > > > error has occurred in this transaction state. Seems like reasonable
> > > > > behavior.
> > > >
> > > > Select command don't start transaction - it is not good
> > >
I do this to begin with (createdb -T template0 db).
FYI: Here's what I've determined is the best thing to do:
1. create the database from template0
2. create the needed languages (plpgsql, plperl, plpython) in the database
3. create the needed tables, functions, types, etc. from script files
Tom Lane wrote:
> An example of how this would simplify life: consider the problem of
> a client that wants to ensure autocommit is on. A simple
> SET autocommit TO on;
> doesn't work at the moment: if autocommit is off, then you'll need
> to issue a COMMIT as well to get out of the implici
I am confused. This wording seems fine to me.
---
Oliver Elphick wrote:
> On Tue, 2002-09-10 at 00:50, Philip Warner wrote:
>
> > ALTERNATIVELY, define the language in template1, then just edit dump1.lis
> > to remove th
I am waiting for this thread to conclude before deciding exactly what to
do for the jdbc driver for 7.3. While using the 'set autocommit true'
syntax is nice when talking to a 7.3 server, the jdbc driver also needs
to be backwardly compatible with 7.2 and 7.1 servers. So it may just be
easier to
> > Don't doubt it at all, but that reminds me: I need to add a message
> > reminding the developer to re-initdb when installing this version.
>
> The catversion check isn't good enough for you?
Nope, it's good enough and then some. I've gotten in the habit of
just re-initdb'ing and figured tha
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Don't doubt it at all, but that reminds me: I need to add a message
> reminding the developer to re-initdb when installing this version.
The catversion check isn't good enough for you?
It seems you are busily reinventing a bunch of decisions that hav
I realise that this has already been done, by Joe Conway I think. Indeed I was
looking at this just before beta1 when I happened to notice the post giving the
plpgsql function. However, as I had started work on it and I was interested in
seeing how things should be done I continued, only not in
> > Has there been any talk of doing incremental -snapshots of the
> > code base?
>
> I don't really see the point. Snapshots of development code are
> available from CVS anyway -- and if you're going to be running a
> pre-alpha version of a relational database, I don't think that
> knowledge of
> > > > It starts a transaction, failes the first command and goes into the
> > > > error has occurred in this transaction state. Seems like reasonable
> > > > behavior.
> > >
> > > Select command don't start transaction - it is not good
> >
> > I think you need more justification than "it is not
> > Agreed, however some of the loop-unrolling might prove to have some
> > optimization, but we'll see. I'd like to think that there's some
> > actual value in -O6 beyond the geek appeal of being able to say it's
> > been compiled with all the optimizations possible. ::shrug::
>
> BTW, -O3 is
Oliver Elphick wrote:
> Available memory (512M) exceeds the total database size, so sequential
> and random are almost the same for the second and subsequent runs.
>
> Since, in production, I would hope to have all active tables permanently
> in RAM, would there be a case for my using a page cos
OK, what you are seeing here is that for your platform the TESTCYCLES
size isn't enough; the numbers are too close to measure the difference.
I am going to increase the TESTCYCLES from 5k to 10k. That should
provide better numbers.
-
On Tue, 10 Sep 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Mon, 9 Sep 2002, Bruce Momjian wrote:
> >> All the problems here are coming from INSTEAD rules. We don't have
> >> INSTEAD triggers or contraints.
>
> > Sure we do, well sort of. :)
> > Make a before trigger
Vanmunin Chea <[EMAIL PROTECTED]> writes:
> // This one is not working
> typedef struct Myindex {
> double *indexes;
> int level;
> int size;
> } Myindex
You cannot use a pointer inside a Postgres datatype. The system will
have no idea that the pointer is there and so will not
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Why is "rules firing in an unpredicatable order" a bug but "returned
> affected tuple count is wrong " just a compatibility issue ?
> Afaik, rule firing order has never been promised, while pqCmdTuples()
> has.
There has never been any spec saying exact
>
> I'm stuck for strange reason!
> This is my first attempt to use pg_lo concept in my apps:
>
> ...
> Oid oid;
> PGconn* dbcon = PQconnectdb(conninfo.c_str());
> oid = lo_creat(dbcon, INV_WRITE | INV_READ);
> int pgfd = lo_open(dbcon, oid, INV_WRITE | INV_READ);
> ...
>
>
> lo_open ALWAY
Karel Zak <[EMAIL PROTECTED]> writes:
> On Mon, Sep 09, 2002 at 11:51:08AM -0400, Tom Lane wrote:
>>> PostgreSQL executor modify query planns?
>>
>> Yes, and yes. Unfortunately.
> Hmm, it's bad. Is there any way to "fix" executor?
It should be fixed IMHO ... but it'll be a major restructuring
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I will run it some more tomorrow but clearly we are
> seeing reasonable numbers now.
... which still have no provable relationship to the ratio we need to
measure. See my previous comments to Curt; I don't think you can
possibly get trustworthy results
Neil Conway <[EMAIL PROTECTED]> writes:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
>> Has there been any talk of doing incremental -snapshots of the code
>> base?
> I don't really see the point. Snapshots of development code are
> available from CVS anyway -- and if you're going to be running
Curt Sampson <[EMAIL PROTECTED]> writes:
> Well, for the sequential reads, the readahead should be trigerred
> even when reading from a raw device.
That strikes me as an unportable assumption.
Even if true, we can't provide a test mechanism that requires root
access to run it --- raw-device test
Curt Sampson <[EMAIL PROTECTED]> writes:
> From Date's _A Guide to the SQL Standard_ (Fourth Edition):
> ...
> The following SQL statements are _not_ transaction-initiating:
> CONNECT
> SET CONNECTION
> DISCONNECT
> SET SESSION AUTHORIZATION
> SET CATALOG
>
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 9 Sep 2002, Bruce Momjian wrote:
>> All the problems here are coming from INSTEAD rules. We don't have
>> INSTEAD triggers or contraints.
> Sure we do, well sort of. :)
> Make a before trigger that does a different statement and returns NULL
>
On Tuesday 10 September 2002 04:16 am, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> > > On Tue, 10 Sep 2002, snpe wrote:
> > > > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > > > On Mon, 2002-09-09 at 17:0
Dear PostgreSQL people,
Sorry for jumping into this conversation in the middle.
Autocommit is very important, as appservers may turn it on or off at
will in order to support EJB transactions (being able to set them up, roll
them back, commit them, etc. by using the JDBC API). If i
Dear all,
I'm currently working on my thesis and I chose psql. What I need to do
is defining a new type in psql.
It should be dynamic array.
| 1 | 2 | 3.0 | 4.5 | 2.1 | . .. . .
// This one is not working
typedef struct Myindex {
double *indexes;
int level;
int size;
HELP!!!
I'm stuck for strange reason!
This is my first attempt to use pg_lo concept in my apps:
...
Oid oid;
PGconn* dbcon = PQconnectdb(conninfo.c_str());
oid = lo_creat(dbcon, INV_WRITE | INV_READ);
int pgfd = lo_open(dbcon, oid, INV_WRITE | INV_READ);
...
lo_open ALWAYS returns -1 whil
On Tue, 2002-09-10 at 00:50, Philip Warner wrote:
> ALTERNATIVELY, define the language in template1, then just edit dump1.lis
> to remove the line for the language definition, and run pg_restore -L
> dump1.lis.
That doesn't work for a dump and reload, because 7.3's pg_dumpall writes
a script t
On Mon, 2002-09-09 at 07:13, Bruce Momjian wrote:
>
> OK, turns out that the loop for sequential scan ran fewer times and was
> skewing the numbers. I have a new version at:
>
> ftp://candle.pha.pa.us/pub/postgresql/randcost
Latest version:
olly@linda$
random test: 14
sequential
I was attempting to measure random page cost a while ago -
I used three programs in this archive :
http://techdocs.postgresql.org/markir/download/benchtool/
It writes a single big file and seems to give more realistic
measurements ( like 6 for a Solaris scsi system and 10 for a Linux ide
one.
Is there any way to determine the location of files in a database
without being the postgres user? Essentially i'm after the setting of
PGDATA so i can then show disk status (df) for that partition.
The pg_database catalogue has 'datpath':
If the database is stored at an alternative location th
>OK, I have a better version at:
The script is now broken, I get:
Collecting sizing information ...
Running random access timing test ...
Running sequential access timing test ...
Running null loop timing test ...
random test: 14
sequential test: 16
null timing test: 14
random_page_cost
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: 10 September 2002 05:58
> To: Sean Chittenden
> Cc: Tom Lane; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Optimization levels when compiling
> PostgreSQL...
>
>
> Sean Chittenden <[EMAIL PROTECTED]> writes:
>
On Mon, 2002-09-09 at 21:25, Ross J. Reedstrom wrote:
> And this has got to be trolling: PostgreSQL is one of the _most_
> stability and correctness focused software projects I've ever known. In
> this particular case, the complaints about this issue where "Your bugfix
> broke my tool! make it bet
> Oh, this is bad news. The problem we have is that rules don't
> distinguish the UPDATE on the underlying tables of the rule from other
> updates that may appear in the query.
>
> If we go with Tom's idea and total just UPDATE's, we will get the right
> answer when there is only one UPDATE in
1 - 100 of 101 matches
Mail list logo
