"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Most importantly, other references I have state that: the ANSI SQL-99
> specification does require that if a statement errors then only that
> statement's changes are rolled back.
No. The spec says
The execution of a may be initiated implicit
I wrote:
Yeah. 7.4 performed a lot better for me. I was a little too greedy in my
hopes that the temp table issue hadn't been addressed and would see
further temp table-related performance gains in 7.5. I see the CVS
commit Aug. 6 before the pgindent run Sept. 4:
http://developer.postgresql.or
Christopher Kings-Lynne wrote:
- All operations on TEMP relations are no longer logged in WAL, nor are
they involved in checkpoints, thus improving performance. (Tom)
That is great news!
Looking forward to 7.5 already,
I could have sworn that the above was done in 7.4, by Tom...?
Yeah. 7.4 pe
- All operations on TEMP relations are no longer logged in WAL, nor are
they involved in checkpoints, thus improving performance. (Tom)
That is great news!
Looking forward to 7.5 already,
I could have sworn that the above was done in 7.4, by Tom...?
Chris
---(end of bro
Simon Riggs wrote:
- All operations on TEMP relations are no longer logged in WAL, nor are
they involved in checkpoints, thus improving performance. (Tom)
That is great news!
Looking forward to 7.5 already,
Mike Mascari
---(end of broadcast)---
POSTGRESQL: Summary of Changes since last release (7.4.1)
--
10 Feb 2004
This is a summary of most changes since code versions marked 7_4_1. The
intention is to help everybody understand what's coming and what might
be affected, though most i
>Andrej Czapszys
> This is a major bug which greatly diminishes the confidence of my
> co-workers in postgresql.
This is NOT a bug. Transactional robustness is important and PostgreSQL
has a very strict implementation in this area.
>Greg Stark
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Edw
Bruce Momjian wrote:
However, we really have two types of function tested.
The first, strerror, can be thread safe by using thread-local storage
_or_ by returning pointers to static strings. The other two function
tests require thread-local storage to be thread-safe.
You are completely ignori
Manfred Spraul wrote:
> Tom Lane wrote:
>
> >Wait a minute. I am *not* buying into any proposal that we need to
> >support ENABLE_THREAD_SAFETY on machines where libc is not thread-safe.
> >We have other things to do than adopt an open-ended commitment to work
> >around threading bugs on obsolete
On 02/06/04:05/5, Tom Lane wrote:
> To: Joe Conway <[EMAIL PROTECTED]>
> Cc: Peter Eisentraut <[EMAIL PROTECTED]>,
> Thomas Hallgren <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Advice regarding configuration parameters
> Date: Fri, 06 Feb 2004 13:15:02 -0500
> Mes
Can't they just let the old index continue to work while generating the new
index and then after the new index is created switch? I know the details are
more complex but what would be the factor(s) preventing this?
Keith
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED
On Tue, 2004-02-10 at 15:40, Rod Taylor wrote:
> On Tue, 2004-02-10 at 15:37, Robert Treat wrote:
> > On Tue, 2004-02-10 at 13:20, Rod Taylor wrote:
> > > > >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
> > >
> > > > Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
>
Bruce Momjian wrote:
>
> What do people want to do with the current \copy behavior for stdin?
> Right now if you supply a file name with queries using psql -f, the copy
> input is read from the terminal, not from the file.
Actually, I was wrong. Right now \copy reads from psql's stdin, not
alwa
Andrew Sullivan wrote:
> On Tue, Feb 10, 2004 at 12:33:10PM -0500, Bruce Momjian wrote:
> >
> > What do people want to do with the current \copy behavior for stdin?
>
> I'd like to hear more discussion of Tom's argument about security
> before the decision is taken.
Tom's point is that you can
On Tue, 2004-02-10 at 13:20, Rod Taylor wrote:
> > >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
>
> > Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
>
> Actually, the one I noticed was the ability to add or rebuild indexes on
> the fly. That is a pretty slick tric
On Tue, 2004-02-10 at 15:37, Robert Treat wrote:
> On Tue, 2004-02-10 at 13:20, Rod Taylor wrote:
> > > >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
> >
> > > Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
> >
> > Actually, the one I noticed was the ability to add
> >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
> Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
Actually, the one I noticed was the ability to add or rebuild indexes on
the fly. That is a pretty slick trick.
---(end of broadcast)
On Tue, Feb 10, 2004 at 12:33:10PM -0500, Bruce Momjian wrote:
>
> What do people want to do with the current \copy behavior for stdin?
I'd like to hear more discussion of Tom's argument about security
before the decision is taken.
--
Andrew Sullivan
---(end of broad
Mark Feit <[EMAIL PROTECTED]> writes:
> What precipitated the patch in the first place was a need to be able
> to do copies in-line to populate tables with small amounts of initial
> data.
Right, that's clearly useful. The debate at hand is about the
usefulness of the other behavior.
BTW, pg_dum
On Tue, 10 Feb 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> No it doesn't. EOF will do fine. The source program doesn't
> >> necessarily have to know anything about COPY, as long as its output is
> >> in a format COPY can cope with (eg, tab-delimited
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I propose we not break existing applications. If we change it the way
> >> you suggest, there'll be no way to do the above.
>
> > But does anyone use such a capability?
>
> What, you're going to remove a feature
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> No it doesn't. EOF will do fine. The source program doesn't
> >> necessarily have to know anything about COPY, as long as its output is
> >> in a format COPY can cope with (eg, tab-delimited).
>
> > The current
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No it doesn't. EOF will do fine. The source program doesn't
>> necessarily have to know anything about COPY, as long as its output is
>> in a format COPY can cope with (eg, tab-delimited).
> The current behavior seems quite strange a
What do people want to do with the current \copy behavior for stdin?
Right now if you supply a file name with queries using psql -f, the copy
input is read from the terminal, not from the file.
I propose changing that so psql reads \copy input from the file so it is
consistent with COPY and is m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I will do it by vote, not because _I_ decide it is unintuitive. And I
> don't have to talk _you_ into it, just a majority of developers.
[shrug...] Put it to a vote if you want; I feel sure you will lose.
There is another argument in favor of being abl
Mark Gibson <[EMAIL PROTECTED]> writes:
> Unfortunately, it doesn't work using the oid the map, whether custom types
> are involved or not. All I get is the following message:
> ERROR: unsupported byval length:
> SPI is very new to me (like 2 days old ;).
> Any suggestions where I've gone wro
Joe Conway wrote:
Without actually having tried it, I think you could hack
pgresultGetTupleDesc() in dblink.c. Replace the line: atttypid =
PQftype(res, i); with an SPI based local lookup using attname.
Hi,
Well I've been adventuring into the realms of SPI and dblink over
the last couple of
Manfred Spraul wrote:
> From fe-secure.c:
>
> > /*
> > * Indicates whether the current thread is in send()
> > * For use by SIGPIPE signal handlers; they should
> > * ignore SIGPIPE when libpq is in send(). This means
> > * that the backend has died unexpectedly.
> > */
Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
> >> return false; /* No threading, so we can't be in send() */
>
> > Why not? Signal delivery can interrupt send() even with single-threaded
> > users.
>
> It looks like Bruce left the old logic in place for unthreaded
> implementat
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I propose we not break existing applications. If we change it the way
>> you suggest, there'll be no way to do the above.
> But does anyone use such a capability?
What, you're going to remove a feature because you don't think it's
us
Yes MS tools for MS SQL have always been there strong point. Easy to get
started and get things going quickly. I on the other hand have never ran
into a lack of flexibility with the client APIs or the stored procedure
syntax.
In all cases I have encountered we have turned away from MS SQL because
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 'psql test for input from stdin. Why would we want STDIN to read from the terminal
> if all commands are being read from a file with -f?
Actually, that behavior is extremely useful. Consider
program-that-generates-data | psql -f somescript
The
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 'psql test > for input from stdin. Why would we want STDIN to read from the terminal
> > if all commands are being read from a file with -f?
>
> Actually, that behavior is extremely useful. Consider
> program-that-generates-d
Just stumbled upon this. just an FYI,
http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
Also, kick-arse Oracle analytic features:
http://www.akadia.com/services/ora_analytic_functions.html
Chris
---(end of broadcast)---
TIP 3: if po
Mark Feit wrote:
> This patch against 7.4.1's psql and the documentation adds the option
> of reading rows from the "current" input stream (standard input, -f
> xxx, \i xxx) during a "\copy ... from" operation in psql. The details
> were proposed and discussed (somewhat) here:
>
> http://archiv
Most of the new features are new database tools, etc. That has always
been a strong point with SQL server. IMO, the weak point of the
database (aside from the vendor and the price), is a lack flexibility of
the client APIs and the stored procedure syntax.
The interesting features are the xml q
Hi all,
Just stumbled upon this. just an FYI,
http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
Shridhar
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command t
Just updated now. compiles. fast fix :-)
Tom Lane wrote:
I plan to fix that later tonight
if no one beats me to it.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.or
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> IIRC, that is the behavior pre-7.4, but you can choose other behaviors
>> in 7.4.
> This is 7.4.1, server and client.
Then see "sslmode" in the libpq docs.
regards, tom lane
---(end of broadca
Does this mean that libpq always attempts to connect in SSL mode and
then falls back?
IIRC, that is the behavior pre-7.4, but you can choose other behaviors
in 7.4.
This is 7.4.1, server and client.
Chris
---(end of broadcast)---
TIP 7: don't for
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Does this mean that libpq always attempts to connect in SSL mode and
> then falls back?
IIRC, that is the behavior pre-7.4, but you can choose other behaviors
in 7.4.
regards, tom lane
---(end
41 matches
Mail list logo
