Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The Perl build (PL/Perl and the Pg interface) now use the configured
> compiler and flags and none of the MakeMaker stuff. (I've kept the
> interfaces/perl5/Makefile.PL file in case someone wants to resurrect it
> for a Win32 build, for instance.) S
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> I'm tempted to suggest that we should stick _P on *all* the
>> lexer token
>> symbols, rather than having an inconsistent set of names where some of
>> them have _P and some do not. Or perhaps _T (for token)
>> would be a more
>> sensible convention;
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 30, 2002 3:25 PM
> To: Christopher Kings-Lynne
> Cc: Katherine Ward; Thomas Lockhart; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Small changes to facilitate Win32 port
>
>
> "Christopher Kings-Lynne"
> -Original Message-
> From: Hannu Krosing [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 30, 2002 1:17 PM
> To: Josh Burdick
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] finding medians
>
>
> On Fri, 2002-05-31 at 01:16, Josh Burdick wrote:
> > BUG: this isn't p
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> It's more likely that your changes will go through if you just submit a
> patch!
I think the question was more directed at "do we like these names?",
which should certainly be asked before going to the trouble of making a
patch.
>> 2. Add
On Fri, 2002-05-31 at 01:16, Josh Burdick wrote:
> BUG: this isn't properly set up to deal with multiple users.
> For example, if A computes a median, then B could read the data
> from the median_tmp table. Possibly you could fiddle with
> transaction isolation levels, or add a user field to medi
It's more likely that your changes will go through if you just submit a
patch!
cvs diff -c
Chris
- Original Message -
From: "Katherine Ward" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 2:33 PM
Subject: [HACKERS] Small changes to facilitate Win32 port
> Hi
Josh Burdick <[EMAIL PROTECTED]> writes:
> illustrates the limitations of the current aggregate function setup,
> which works so nicely for avg() and stddev().
> I don't have any good solutions. I tried using a float4[] to store
> each element as it's added, but I couldn't get array updates
Hi there. I'm yet another developer working full-time on a native windows
port. I'm also working closely with Jan Wieck (next office). I know there is
a reluctance to modify the code base to support native win32, and I realize
that no decision has yet been made. However, ...
A few of the iden
Here is a program written in C that demonstrates 2 median/selection
computation techniques:
ACM Algorithm 727 (implementation by Sherif Hashem)
QuickSelect (implemented by me).
Since it is written in C, it would be useful to PostgreSQL project
without any fanfare.
ftp://cap.connx.com/pub/chess-e
ACK! Sorting to find a median is criminal.
"Introduction to Algorithms" by Thomas H. Cormen, Charles E. Leiserson,
Ronald L. Rivest
ISBN: 0262031418
explains the better algorithm very well.
Here is a freely available C++ template (written by me) for a bunch of
statistics (everything *but* the s
Josh,
> At the end of this message is some code I used to find medians.
> It's kind of a hack, but approximately works, and is intended as a
> somewhat awkward stopgap for people who need to use medians. It
> illustrates the limitations of the current aggregate function setup,
> which
At the end of this message is some code I used to find medians.
It's kind of a hack, but approximately works, and is intended as a
somewhat awkward stopgap for people who need to use medians. It
illustrates the limitations of the current aggregate function setup,
which works so nicely
Neil Conway <[EMAIL PROTECTED]> writes:
> What does everyone think about adding self-tuning histograms
> to PostgreSQL?
> [ snip ]
> I think that ST histograms would be useful because:
> (1) It would make it easier for us to implement multi-dimensional
> histograms (for more info, see the Abo
"Joel Burton" <[EMAIL PROTECTED]> writes:
> Is there any generalizable help would could offer to people who write
> functions that have side effects? Don't use them in WHERE (or ON or HAVING)
> clauses? Evaluate the function in a earlier db call, then plug the resolved
> results into the SQL WHERE
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 30, 2002 10:44 AM
> To: Joel Burton
> Cc: Alessio Bragadini; PostgreSQL Hackers
> Subject: Re: [HACKERS] wierd AND condition evaluation for plpgsql
>
>
> "Joel Burton" <[EMAIL PROTECTED]> writes:
> >>> A
"Joel Burton" <[EMAIL PROTECTED]> writes:
>>> Actually, at least in some cases, PG does short-circuit logic:
>>> joel@joel=# select false and seeme();
>>> joel@joel=# select true and seeme();
>> If seeme() returns NULL, shouldn't both SELECTs return NULL, and
>> therefore not be short-circuit-abl
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Do we need to fix GiST code for 7.3 ?
No, I think it's fine. I had forgotten that old discussion ...
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extens
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Alessio
> Bragadini
> Sent: Thursday, May 30, 2002 9:04 AM
> To: PostgreSQL Hackers
> Subject: Re: [HACKERS] wierd AND condition evaluation for plpgsql
>
>
> On Tue, 2002-05-28 at 16:09, Joel Burton wro
On Tue, 2002-05-28 at 16:09, Joel Burton wrote:
> Actually, at least in some cases, PG does short-circuit logic:
> joel@joel=# select false and seeme();
> joel@joel=# select true and seeme();
If seeme() returns NULL, shouldn't both SELECTs return NULL, and
therefore not be short-circuit-able?
On Tue, May 28, 2002 at 06:08:21PM -0700, Thomas Lockhart wrote:
> clients. We have been very low-key (imho) in representing this solution
> to the developer community, but it should be considered for applications
> matching its capabilities.
I should like to emphasise that I have no desire to
Glad to hear GiST in 7.2 isn't broken :-)
We miss the topic, what was the problem ?
Do we need to fix GiST code for 7.3 ?
proposal for null-safe GiST interface is available
http://fts.postgresql.org/db/mw/msg.html?mid=1028327
and discussion
http://fts.postgresql.org/db/mw/msg.html?mid=1025848
22 matches
Mail list logo
