Luke Lonergan said:
> Andrew,
>
>> I will be the first to admit that there are probably some very good
>> possibilities for optimisation of this code. My impression though has
>> been that in almost all cases it's fast enough anyway. I know that on
>> some very modest hardware I have managed to loa
On Wed, 2005-06-01 at 11:30 +0200, Pavel Stehule wrote:
> I did small trivial patch (almost all was written) for storing
> result from executing dynamic query into ROW or RECORD variable.
Cool, this will be useful. A few minor comments:
The patch needs some regression tests.
I'm not sure
On Sun, 2005-05-22 at 21:25 +0530, Abhijit Menon-Sen wrote:
> I have attached the following seven patches to address this problem:
Does anyone with the skills to review this (i.e. someone other than me)
have any comments on this patch?
Otherwise I'll apply it in a day or two.
-Neil
--
On Sun, 2005-05-08 at 19:00 +0200, Dennis Bjorklund wrote:
> Here is a small patch that implements a function lastval() that
> works just like currval() except that it give the current
> value of the last sequence used by nextval().
Have you had a chance to respin this patch per my earlier comment
This patch simplified Win32 signaling code per discussion in hackers. In
this implementation, each process will have a named (by its pid) mutex,
named shared memory area and named event in global namespace. The process
is
sending/receiving signals as the following:
(*) the process who kill the si
> This patch simplified Win32 signaling code per discussion in
> hackers. In this implementation, each process will have a
> named (by its pid) mutex, named shared memory area and named
> event in global namespace. The process is sending/receiving
> signals as the following:
>
> (*) the proces
Andrew,
> OK ... that seems fair enough. The next question is where the data being
> loaded comes from? pg_dump? How does load speed compare with using COPY's
> binary mode?
Oddly, our tests in the past have shown that binary is actually slower.
Luke
---(end of broadca
Pavel Stehule wrote:
http://www.techonthenet.com/oracle/functions/add_months.htm
http://www.techonthenet.com/oracle/functions/last_day.htm
http://www.techonthenet.com/oracle/functions/next_day.htm
http://www.techonthenet.com/oracle/functions/months_between.htm
Are these functions useful enough
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
>
> Looking at this patch reminds me of another discussion we had:
>
> Signals sent by the postmaster *before the signaling code is running in
> the child* has to be handled.
>
> This is handled in the curernt code by creating the pipe in the
> postma
On Fri, 3 Jun 2005, Neil Conway wrote:
> Pavel Stehule wrote:
> > http://www.techonthenet.com/oracle/functions/add_months.htm
> > http://www.techonthenet.com/oracle/functions/last_day.htm
> > http://www.techonthenet.com/oracle/functions/next_day.htm
> > http://www.techonthenet.com/oracle/functions
Pavel Stehule wrote:
On Fri, 3 Jun 2005, Neil Conway wrote:
Pavel Stehule wrote:
http://www.techonthenet.com/oracle/functions/add_months.htm
http://www.techonthenet.com/oracle/functions/last_day.htm
http://www.techonthenet.com/oracle/functions/next_day.htm
http://www.techonthenet.com/oracle/
On Thu, Jun 02, 2005 at 05:41:46PM +0200, Pavel Stehule wrote:
> My next patch is implementation least and greatest functions. If
> will possible I prefere contrib for it, but it's inpossible. I had
> to modify parser. I know so there exists workaround of its, but it's
> really ugly.
BTW, the t
On Thu, Jun 02, 2005 at 09:17:07AM -0700, Joshua D. Drake wrote:
> Pavel Stehule wrote:
> >>
> >>Are these functions useful enough to be provided as builtins?
> >>add_months(), for example, seems to be a less general version of
> >>'date' + 'interval'.
>
> Why not a pgFoundry project called Oracle
>
> Why not a pgFoundry project called Oracle-Compat or something? There
> are plenty of functions etc... that can be included in the package as a
> whole.
>
> Once it is large enough, push it to contrib or vie for core support.
>
Is exists. Not in very usefull state, true.
http://pgfoundry.
Pavel Stehule <[EMAIL PROTECTED]> writes:
> b) some functions need patch to parser - greatest, least and decode.
Why?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
On Thu, 2 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> > b) some functions need patch to parser - greatest, least and decode.
>
> Why?
>
they has variable number of argument, they are polymorphic. They are not
functions, more special form of operators.
Maybe it is p
On Thu, 2005-06-02 at 11:39 +1000, Neil Conway wrote:
> On Wed, 2005-06-01 at 17:08 -0700, Mary Edie Meredith wrote:
> > I know I'm late to this discussion, and I haven't made it all the way
> > through this thread to see if your questions on Linux writes were
> > resolved. If you are still inter
Neil Conway said:
> On Sun, 2005-05-22 at 21:25 +0530, Abhijit Menon-Sen wrote:
>> I have attached the following seven patches to address this problem:
>
> Does anyone with the skills to review this (i.e. someone other than me)
> have any comments on this patch?
>
> Otherwise I'll apply it in a day
On Thu, 2005-06-02 at 18:53 +0200, Pavel Stehule wrote:
> I expect so less used functions will go to contrib: LNNVL, .. but some
> functions can by general usefull. There is WIDTH_BUCKET in core too now.
> Who use it?
width_bucket() is defined by SQL2003, and is included largely for
compliance
On Thu, 2005-06-02 at 11:49 -0700, Mary Edie Meredith wrote:
> My understanding is that O_DIRECT means "direct" as in "no buffering by
> the OS" which implies that if you write from your buffer, the write is
> not going to return unless the OS thinks the write is completed
Right, I think that's d
FYI - we're prepping a proposal for just that. Stay tuned for Alon's
proposal.
Luke
On 6/1/05 11:43 PM, "Neil Conway" <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-02 at 00:53 -0400, Alon Goldshuv wrote:
>> My thoughts were -- see how the responses are, and if people think
>> that this is a bet
On Mon, 2005-05-23 at 18:52 +0800, Qingqing Zhou wrote:
> Now \d+ is able to show the tablespace details of indices.
Should this be included in \d? Tablespace information for the table
itself is, so I think we should probably do the same for indexes.
Also, can you resend the patch as an attachmen
I expect so less used functions will go to contrib: LNNVL, .. but some
functions can by general usefull. There is WIDTH_BUCKET in core too now.
Who use it?
Width_bucket is in the sql standard...
---(end of broadcast)---
TIP 1: subscribe and uns
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-05-23 at 18:52 +0800, Qingqing Zhou wrote:
>> Now \d+ is able to show the tablespace details of indices.
> Should this be included in \d? Tablespace information for the table
> itself is, so I think we should probably do the same for indexes.
In thread:
http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00010.php
---
>Do we actually need to pass the handle, or could the subprocess reopen
>the pipe for itself?
Nope, we need to pass the handle. Only one process can be the
server-side of the pipe, and once the postmaster has o
On Thu, 2005-06-02 at 22:15 -0400, Tom Lane wrote:
> Does that look better or worse to you?
I agree the patch's format is a bit off. What about
"mi" btree (i), tablespace "testspace"
"PRIMARY KEY" is currently separated from the rest of the index
description via a comma -- although on the o
26 matches
Mail list logo
