On Tue, 21 Jun 2005, Bruce Momjian wrote:
> Pavel Stehule wrote:
> > Hello,
> >
> > I sended version with only LEAST and GREATEST
> > http://archives.postgresql.org/pgsql-patches/2005-06/msg00185.php
>
> OK, did you remove DECODE for a reason?
>
o simplify patch
o decode can be added in fu
this patch is last
Pavel
On Tue, 21 Jun 2005, Bruce Momjian wrote:
> Pavel Stehule wrote:
> > Hello,
> >
> > I sended version with only LEAST and GREATEST
> > http://archives.postgresql.org/pgsql-patches/2005-06/msg00185.php
> >
> > this patch contains diff files for NEXT_DAY and LAST_DAY func
Neil Conway wrote:
Attached is a patch that I believe should implement what the author
intended.
Applied.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Magnus Hagander wrote:
This patch removes Kerberos version 4 support from the backend and
libpq.
I'll apply this later today, barring any objections.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister com
Neil Conway wrote:
Attached is a revised patch.
Patch applied -- thanks, Pavel. I ended up using ERRCODE_SYNTAX_ERROR
when a CONTINUE is specified outside a loop. BTW, one minor annoyance is:
<>
BEGIN
LOOP
CONTINUE lbl;
END LOOP;
END;
The current implementation will raise an
That attached 2 patches implement a validator function for plperl, and
support for it in createlang.
This has somewhat less utility than do such functions for languages with
stricter compiletime as opposed to runtime requirements, but I still
think it's useful. If this is acceptable I'll pro
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I will apply the LEAST/GREATEST parts and see if others can argue
> > for decode().
>
> Actually, I'd like to review the patch before it goes in --- if anyone's
> looked at the code, I saw no comments about it ...
No, no one commented. I wanted to
This patch removes Kerberos version 4 support from the backend and
libpq. Per previous mail, I sent a mail to both hackers and -general
about a month ago asking for ppl who use it, for zero responses. I also
looked back in the archives and it seems it has been asked before and
also not responded, s
Bruce Momjian writes:
> OK, I will apply the LEAST/GREATEST parts and see if others can argue
> for decode().
Actually, I'd like to review the patch before it goes in --- if anyone's
looked at the code, I saw no comments about it ...
regards, tom lane
---
Tom Lane wrote:
> Bruce Momjian writes:
> > Oh, and I personally think DECODE is fine, even if it partly duplicates
> > something we already have. I was just asking to make sure everyone else
> > was OK before I applied it.
>
> I would rather not have a useless variant spelling of CASE ...
> LEA
Bruce Momjian writes:
> Oh, and I personally think DECODE is fine, even if it partly duplicates
> something we already have. I was just asking to make sure everyone else
> was OK before I applied it.
I would rather not have a useless variant spelling of CASE ...
LEAST/GREATEST at least do someth
Pavel Stehule wrote:
> Hello,
>
> I sended version with only LEAST and GREATEST
> http://archives.postgresql.org/pgsql-patches/2005-06/msg00185.php
OK, did you remove DECODE for a reason?
> this patch contains diff files for NEXT_DAY and LAST_DAY function too,
> which I think are generally use
If dbsize is being moved from contrib to the backend, it should be moved
in in its entirety ...
On Tue, 21 Jun 2005, Bruce Momjian wrote:
This version is being removed from the patches queue because it does not
address how to handle existing dbsize functions not moved into the main
server.
Hello,
I sended version with only LEAST and GREATEST
http://archives.postgresql.org/pgsql-patches/2005-06/msg00185.php
this patch contains diff files for NEXT_DAY and LAST_DAY function too,
which I think are generally usefull.
There is duplicity with CASE.
Regards
Pavel
On Tue, 21 Jun 2005,
Pavel Stehule wrote:
> Hello,
>
> I sended version with only LEAST and GREATEST
> http://archives.postgresql.org/pgsql-patches/2005-06/msg00185.php
>
> this patch contains diff files for NEXT_DAY and LAST_DAY function too,
> which I think are generally usefull.
>
> There is duplicity with CASE
This version is being removed from the patches queue because it does not
address how to handle existing dbsize functions not moved into the main
server.
---
Andreas Pflug wrote:
> As a start for a bunch of instrumentation f
This patch looks good. I know greater/least are seen as valuable, but
do we want decode()? It seems OK to me but I thought there was concern
about it in the past because it duplicated some existing functionality.
---
Pavel
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Jun 21, 2005 at 04:03:43PM +0300, Eugen Nedelcu wrote:
>> This is a patch for psql client and not for the backend.
> I think it would be much nicer if it was a backend setting.
Doing this as a backend setting has been proposed and rejected befo
On Tue, Jun 21, 2005 at 04:03:43PM +0300, Eugen Nedelcu wrote:
> This is a patch for psql client and not for the backend. It's role
> is to output numbers to screen in easy readable form (2,345,675,454,543
> is much easier to read then 2345675454543.456). I think graphical
> clients like pgAdmin
On Tue, Jun 21, 2005 at 16:03:43 +0300,
Eugen Nedelcu <[EMAIL PROTECTED]> wrote:
>
> This is a patch for psql client and not for the backend. It's role
> is to output numbers to screen in easy readable form (2,345,675,454,543
> is much easier to read then 2345675454543.456). I think graphical
>
On Tue, Jun 21, 2005 at 06:59:38AM -0500, Bruno Wolff III wrote:
> On Tue, Jun 21, 2005 at 08:42:16 +0300,
> Eugen Nedelcu <[EMAIL PROTECTED]> wrote:
> >
> > One solution to deal with this is to use to_char function, but for
> > complex selects against multiple tables it's not a good option.
>
On Tue, Jun 21, 2005 at 08:42:16 +0300,
Eugen Nedelcu <[EMAIL PROTECTED]> wrote:
>
> One solution to deal with this is to use to_char function, but for
> complex selects against multiple tables it's not a good option.
Why not? You only have to apply it to the output expressions that
need it.
N
- Updated to current cvs.
- pg_terminate_backend omitted
- contrib/dbsize cleaned to reflect move of functions to core
Index: contrib/dbsize/README.dbsize
===
RCS file: /projects/cvsroot/pgsql/contrib/dbsize/README.dbsize,v
retrievin
Pavel Stehule wrote:
Attached patch provide continue stmt in plpgsql language. Continue stmt
start new step in any loop stmt. If stmt continue is in begin end block,
then find first outer loop (per recent discussion).
Attached is a revised patch. I didn't see anything major that needed to
b
24 matches
Mail list logo
