On Tuesday 2005-10-04 13:54, Simon Riggs wrote:
> On Tue, 2005-10-04 at 18:16 +0200, Zeugswetter Andreas DAZ SD wrote:
> > > Another possibility is optimizing for the special case of
> > > indexing on a partitioning key. In this case, index values
> > > would be very localized to one table, so just
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Not a bug fix, but this bug still hasn't been looked at:
> http://archives.postgresql.org/pgsql-hackers/2005-04/msg00499.php
I'm not really convinced that's a bug, and in any case it's not going to
be dealt with in 8.1.
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
My take: we should document this better, but it ain't broke so it don't
need fixing,
Actually, my take on your analysis is that there should be a way to get
at "use warnings" (I assume that's disallowed in trusted plperl).
Core's current plan is to bundle 8.1beta3 tomorrow evening (Tuesday PM,
North American east coast time) for announcement Wednesday. Any last
minute bug fixes out there?
Not a bug fix, but this bug still hasn't been looked at:
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00499.php
C
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> My take: we should document this better, but it ain't broke so it don't
> need fixing,
Actually, my take on your analysis is that there should be a way to get
at "use warnings" (I assume that's disallowed in trusted plperl).
re
Whether this is a good idea is another question entirely. Lots of
people will tell you it's a horrid idea for PG functions to cause
outside-the-database side effects. The reason is that if the
transaction that called the function aborts later, there is no way
to roll back what was done outside t
Whether this is a good idea is another question entirely. Lots of
people will tell you it's a horrid idea for PG functions to cause
outside-the-database side effects. The reason is that if the
transaction that called the function aborts later, there is no way
to roll back what was done outside t
On Mon, 2005-10-10 at 15:57 -0400, Lane Van Ingen wrote:
> That sounds good, and about what I expected. I am not a C programmer, but
> have access to others who are. Where would I need to put the C function
> in order to have PostgreSQL find it? Any special considerations
> other than putting it in
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> A couple questions occur to me, though. I'm not clear on why
> ceil is called -- do we need to eliminate the fraction here?
Well, you don't get to read part of a page. In particular, fetching 1.0
index tuples requires fetching 1.0 pages, not (say) 0
Greg Sabino Mullane wrote:
Core's current plan is to bundle 8.1beta3 tomorrow evening (Tuesday PM,
North American east coast time) for announcement Wednesday. Any last
minute bug fixes out there?
Anyone able to duplicate my plperl bug? If it is genuine, I would really
like to see it fi
Hmmm... With that much direction, I really have no excuse
not to try a change and provide some test cases, do I?
A couple questions occur to me, though. I'm not clear on why
ceil is called -- do we need to eliminate the fraction here?
It seems to me that it wouldn't matter much except when the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Core's current plan is to bundle 8.1beta3 tomorrow evening (Tuesday PM,
> North American east coast time) for announcement Wednesday. Any last
> minute bug fixes out there?
Anyone able to duplicate my plperl bug? If it is genuine, I would really
Hi Guys,
Not sure whether this is the right place to ask this, but
who is looking after the varied mirrors? The NZ mirror
seems badly broken, the index page looks incomplete,
and none of the links seem to work, 404s all over the
place.
Cheers,
Andrej
---(end of broadcast
Core's current plan is to bundle 8.1beta3 tomorrow evening (Tuesday PM,
North American east coast time) for announcement Wednesday. Any last
minute bug fixes out there?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 10/06/05 9:28 PM >>>
>> There's a known issue that the planner tends to overestimate the cost of
>> inner-index-scan nestloops, because it doesn't allow for the strong
>> caching effects associated with repeated scans of th
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> In the past, I've just written a C-based function that calls out to system.
Use pltclu, plpythonu, or plperlu, according to taste. They all have
pre-existing solutions for this.
Whether this is a good idea is another question entirely. Lots of
peo
On Mon, Oct 10, 2005 at 03:40:43PM -0400, Lane Van Ingen wrote:
> I am working on the development of a military application which uses
> PostgreSQL trigger functions. I cannot (unfortunately) tell you
> specify use, being as it is classified.
>
> What I need the ability to occasionally call (execu
Another possibility is to use an untrusted interpreted PL such as
plperlu. That avoids the need for C. Or maybe you could prototype using
plperlu and then translate to C when it's all working. It all depends on
your needs.
cheers
andrew
Lane Van Ingen wrote:
That sounds good, and about w
Thanks, Tom.
I spent a few hours trying different searches in the archives, and
found three very interesting threads on the topic. All were from
2003. Should I keep digging for more recent threads, or would
these probably represent the current state of the issue?
These left me somewhat concer
Some time ago I wrote:
> I've been trying to figure out what to do about pg_dumpall's --clean
> option in view of our recent changes.
(for the rest, see
http://archives.postgresql.org/pgsql-hackers/2005-07/msg01143.php
Since we haven't come up with any bright ideas, and it seems far too
late in t
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Lane Van Ingen
> Sent: Monday, October 10, 2005 12:41 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Need A Suggestion
>
> I am working on the development of a military applic
That sounds good, and about what I expected. I am not a C programmer, but
have
access to others who are. Where would I need to put the C function in order
to
have PostgreSQL find it? Any special considerations other than putting it in
'the right library' ??
-Original Message-
From: Jonah H
On 10/10/05, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > > You can do this today using PAM authenication, but this is
> > not always
> > > possible. Notably it's never possible on Windows, and there are
> > > several unix platforms/distros that don't support it
> > without a lot of
> > > work.
>
In the past, I've just written a C-based function that calls out to system.
2005/10/10, Lane Van Ingen <[EMAIL PROTECTED]>:
> I am working on the development of a military application which uses
> PostgreSQL trigger functions. I cannot (unfortunately) tell you specify use,
> being as it is classi
I am working on the development of a military application which uses
PostgreSQL trigger functions. I cannot (unfortunately) tell you specify use,
being as it is classified.
What I need the ability to occasionally call (execute) a .exe program object
outside of the database from within the function
> > You can do this today using PAM authenication, but this is
> not always
> > possible. Notably it's never possible on Windows, and there are
> > several unix platforms/distros that don't support it
> without a lot of
> > work.
>
> Or you port PAM to Windows, and then everybody wins.
Well,
Folks,
We're bundling up the 8.1 Press Release and Presskit for translation.
BEFORE I send it to the translators, I want to run it quickly past this
list for technical accuracy.
Please don't waste time re-writing for style, wording, theme, etc, unless
you see a really intolerable gaffe. We'v
On Mon, Oct 10, 2005 at 03:56:10PM +0200, Daniel Schuchardt wrote:
> my PostgreSQL 8.0.0 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
>
> crashes when
>
> SELECT * FROM pg_stat_activity WHERE datname=COALESCE(NULL, NULL);
Already reported and fixed as of 8.0.3; consider upgrading (8.0
Hy,
my PostgreSQL 8.0.0 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
crashes when
SELECT * FROM pg_stat_activity WHERE datname=COALESCE(NULL, NULL);
I had an mistake in a stored procedure so COALESCE got 2 NULL values but
a crash is not nice here ;-)
workaround :
SELECT * FROM pg
Hi,
I did see the message about the change of the function signatures to
include IMMUTABLE and thought "Yes, that makes sense" - however, it has
now occurred to me that:
1. xpath_table uses a SELECT query to fetch the data it uses, so should
presumably be marked STABLE?
2. xslt_process is to be
Magnus Hagander wrote:
> You can do this today using PAM authenication, but this is not always
> possible. Notably it's never possible on Windows, and there are
> several unix platforms/distros that don't support it without a lot of
> work.
Or you port PAM to Windows, and then everybody wins.
--
31 matches
Mail list logo
