Hello
I have new version. I'll send it early.
Regards
Pavel Stehule
On Sat, 4 Jun 2005, Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the Postg
Yes please...
... That's exactly what I've been asking for
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
> Sent: Monday, June 06, 2005 12:18 PM
> To: Dennis Bjorklund
> Cc: pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] la
lastval() returns the last value produced by nextval() or setval() in
the current session.
I'm in favour of that definition...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregiste
Tom Lane wrote:
> Bruce Momjian writes:
> >> BTW, I found memory leak in BootStrapXLOG(). The buffer allocated by
> >> malloc()
> >> is not free()ed. ISSUE_BOOTSTRAP_MEMORYLEAK in this patch points out it.
> >> (But this leak is not serious, because this function is called only once.)
>
> > Does
Bruce Momjian writes:
> Tom Lane wrote:
>> You realize this is a waste of code, no?
> I guess, but the person reported a leak so I figured I would fix it.
I don't really care whether there's a free() there or not --- what
bothers me is that calling it a leak shows a fundamental
misunderstanding
On Sat, Jun 04, 2005 at 08:42:29PM -0400, Bruce Momjian wrote:
>
> I am using 'cp' in current CVS for this. I assume it is as fast as the
> C implementation, but if not, please let me know.
Yes, your change did make the installation considerably faster so I
abandoned the binary install idea. Th
Michael Glaesemann wrote:
> Bruce,
>
> Please note that this patch is a correction and replacement for an
> earlier patch in the queue. The patch accompanying the message
> http://candle.pha.pa.us/mhonarc/patches/msg8.html
> should be removed from the queue and not applied.
>
> The one (ori
Tom Lane wrote:
> Bruce Momjian writes:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
>
> > a_ogawa00 wrote:
> >> This patch provides a new function regexp_replace.
> >> regexp_replace extends a replace function and enables text search
> >> by the regular expression.
Bruce Momjian writes:
> Tom Lane wrote:
>> Don't we have this functionality already? It's even SQL-spec ...
> Uh, all I see it replace(), which isn't regex:
The SQL-spec function is substring(string from pattern for escape-char);
see
http://www.postgresql.org/docs/8.0/static/functions-matching
Patch removed because we already have this functionality.
---
a_ogawa00 wrote:
>
> This patch provides a new function regexp_replace.
> regexp_replace extends a replace function and enables text search
> by the regular expr
Nice. Patch removed.
---
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Don't we have this functionality already? It's even SQL-spec ...
>
> > Uh, all I see it replace(), which isn't regex:
>
> The SQL-
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Do we want to make this superuser-only?
>
> Yes, random seeds or so might be deducted from it.
>
> I'd also propose to name this function pg_postmaster_starttime() to
> clarify its purpose. There's already a function of that name in the
> (non-con
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >
> >>This patch reenables pg_terminate_backend, allowing (superuser only, of
> >>course) to terminate a backend. As taken from the discussion some weeks
> >>earlier, SIGTERM seems to be used quite widely, without a report of
Bruce Momjian writes:
> Andreas Pflug wrote:
>> I'd also propose to name this function pg_postmaster_starttime() to
>> clarify its purpose.
> Agreed, or pg_server_start_time()? Which is better?
It's not instantly obvious whether "server" means the postmaster or the
current backend process, so
Tom Lane wrote:
> Bruce Momjian writes:
> > Andreas Pflug wrote:
> >> I'd also propose to name this function pg_postmaster_starttime() to
> >> clarify its purpose.
>
> > Agreed, or pg_server_start_time()? Which is better?
>
> It's not instantly obvious whether "server" means the postmaster or
On Mon, Jun 06, 2005 at 12:02:18PM -0400, Bruce Momjian wrote:
>
> Patch removed because we already have this functionality.
We don't yet have this functionality, as the patch allows for using
second and later regex matches "()" in the replacement pattern.
The function is misnamed. It should be
Hi Bruce,
>
> I think we are best with just pg_startime. If people want the
> interval
> they can subtract it from CURRENT_TIMESTAMP. I have added Matthias's
> version to the patch queue.
>
>
OK. But IIRC the Matthias implementation doesn't work in standalone
mode. And talking about the 'inte
Euler Taveira de Oliveira wrote:
> Hi Bruce,
>
> >
> > I think we are best with just pg_startime. If people want the
> > interval
> > they can subtract it from CURRENT_TIMESTAMP. I have added Matthias's
> > version to the patch queue.
> >
> >
> OK. But IIRC the Matthias implementation doesn't
Bruce Momjian writes:
> I think we should return intervals only when we can't return meaningful
> timestamp values. I don't have any logic to back up that opinion, though.
It's easy: a value measured as an interval will be obsolete by the time
it's delivered to the client. A start timestamp is a
David Fetter wrote:
> On Mon, Jun 06, 2005 at 12:02:18PM -0400, Bruce Momjian wrote:
> >
> > Patch removed because we already have this functionality.
>
> We don't yet have this functionality, as the patch allows for using
> second and later regex matches "()" in the replacement pattern.
>
> The
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
[EMA
I will test this to see if should be the default, or whether we need
VERBOSE.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
-
This patch makes it possible to use the full set of timezones when doing
"AT TIME ZONE", and not just the shorlist previously available. For
example:
SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London';
works fine now. It will also obey whatever DST rules were in effect at
just that date, which
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > The attached zip file (os2port.zip) contains an os2.diff file that has all
> > the patches for the os/2 port and a file os2newfiles.zip file that has the
> > additional files required for the port.
> > [ 130k diff snipped ]
>
> We were willing to tol
Hello
This patch respect last Tom's Lane notes. Is based on first variante,
http://archives.postgresql.org/pgsql-committers/2005-05/msg00303.php
SQLSTATE and SQLERRM are local variables blocks with EXCEPTION clause.
I wonted respect a litlle bit Oracle behavior and therefore exist these
varia
This simple refactoring patch moves all of the code associated with
Partial Index planning into a single file. This isolates it from other
code changes that may take place over the next few months, as well as
setting the scene for a number of changes that will hopefully take place
with that code.
Hello
This patch is second release with changes wia
http://archives.postgresql.org/pgsql-patches/2005-06/msg00024.php
It's trivial, but I houpe usefull.
Regards
Pavel Stehule
diff -c -r --new-file pgsql.01/doc/src/sgml/plpgsql.sgml
pgsql/doc/src/sgml/plpgsql.sgml
*** pgsql.01/doc/src/sgml/
Bruce Momjian wrote:
Is this patch being worked on?
I have shelved it for the moment, waiting on any further comments from
Tom before reworking it.
-O
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Oliver Jowett wrote:
> Bruce Momjian wrote:
> > Is this patch being worked on?
>
> I have shelved it for the moment, waiting on any further comments from
> Tom before reworking it.
I thought he wanted the patch modified so keepalive could never be
turned off, but that the OS default parameters
Christopher Kings-Lynne wrote:
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
And a way of notifying the client that a reset has happened.
-O
---(end of broadcast)--
Hello
This patch contains three oracle users missing functions. But I
hope can be usefull for all PostgreSQL users (users vote me ;-) Certainly
LEAST and GREATEST, which has not analogy. Using of DECODE is similar
CASE, but with some differences. There exist some workarounds in plpgsql,
I think we have concluded that the use of the ICU library is the way we
are going to accomplish multi-locale support in the future.
---
Mahmoud Taghizadeh wrote:
> there was a discussion in postgresql mailing list about usin
I think we have decided that use of the ICU library is the tool we are
going to use to implement muliple locales.
---
Peter Eisentraut wrote:
> Am Montag, 7. Februar 2005 23:24 schrieb Tom Lane:
> > I've been waiting to see
Bruce Momjian wrote:
> David Fetter wrote:
> > On Mon, Jun 06, 2005 at 12:02:18PM -0400, Bruce Momjian wrote:
> > >
> > > Patch removed because we already have this functionality.
> >
> > We don't yet have this functionality, as the patch allows for using
> > second and later regex matches "()" in
On Tue, Jun 07, 2005 at 09:35:56AM +0900, a_ogawa wrote:
>
> Bruce Momjian wrote:
> > David Fetter wrote:
> > > On Mon, Jun 06, 2005 at 12:02:18PM -0400, Bruce Momjian wrote:
> > > >
> > > > Patch removed because we already have this functionality.
> > >
> > > We don't yet have this functionality,
Bruce Momjian writes:
> I think we have concluded that the use of the ICU library is the way we
> are going to accomplish multi-locale support in the future.
You did? It really seemed like there was one crowd pushing ICU and hardly
anyone else interested in piling a huge library dependency on Po
Greg Stark wrote:
> Bruce Momjian writes:
>
> > I think we have concluded that the use of the ICU library is the way we
> > are going to accomplish multi-locale support in the future.
>
> You did? It really seemed like there was one crowd pushing ICU and hardly
> anyone else interested in piling
Bruce Momjian writes:
> Oliver Jowett wrote:
>> I have shelved it for the moment, waiting on any further comments from
>> Tom before reworking it.
> I thought he wanted the patch modified so keepalive could never be
> turned off, but that the OS default parameters could be changed.
I wanted it
Pavel Stehule wrote:
> [ Patch for EXECUTE INTO in PL/PgSQL ]
Applied to HEAD with some editorializations and improvements. Thanks for
the patch.
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www
Hi Bruce,
> I think we should return intervals only when we can't return
> meaningful
> timestamp values. I don't have any logic to back up that opinion,
> though.
>
Agreed.
>
> We need to preceed our function names with pg_ for cases like this
> where
> we are supplying pg-specific behavior.
>
Neil Conway wrote:
If you're busy, I can clean this up and apply it.
Attached is a revised patch. Per subsequent discussion, I stuck with
your approach of keeping a pointer to the sequence object, rather than
just the last int64 produced by nextval(). That means we emit an error on:
CREATE
On Mon, Jun 06, 2005 at 10:11:15PM -0400, Bruce Momjian wrote:
> Greg Stark wrote:
> > Yes it's true that on some OSes it wouldn't be tolerably efficient but on
> > glibc it's more than tolerable. If better solutions (strxfrm_l) become
> > available at some point in the future then it would be abo
42 matches
Mail list logo
