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
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:
>> 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
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
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
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
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
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
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
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
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:
> 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
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
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.
> > */
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
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
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
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:
> 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
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
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
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
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, 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
> >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, 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
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
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
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
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?
>
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 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
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
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
>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
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
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)---
- 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
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
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
"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
41 matches
Mail list logo
