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
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.
Note
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.
Why not?
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
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
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.
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 usefull.
Bruce Momjian pgman@candle.pha.pa.us 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 ...
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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 pgman@candle.pha.pa.us 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
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
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
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 function too,
14 matches
Mail list logo
