Neil Conway <[EMAIL PROTECTED]> writes:
> Jaime Casanova wrote:
>> Or are any reasons to keep that argument?
> None that I can see. I'll apply the patch later today, barring any
> objections.
Looking at the 7.3 sources, the argument was used to support the
then-existing convention that an error
Bruce Momjian wrote:
> Where are we on this? I do think it solves a problem that some are
> having, and it seems it would detect a disconnected client and abort a
> long running query.
I haven't had a chance to do any work to support the Solaris stuff, but
otherwise I'm just waiting on review.
N
Jaime Casanova wrote:
i found out that the function textToQualifiedNameList doesn't use the
second argument it receive (caller). i suppose in the past was used
and now it is useless, if that is the case here is a patch removing.
Or are any reasons to keep that argument?
None that I can see. I'l
Hi,
i found out that the function textToQualifiedNameList doesn't use the
second argument it receive (caller). i suppose in the past was used
and now it is useless, if that is the case here is a patch removing.
Or are any reasons to keep that argument?
--
regards,
Jaime Casanova
(DBA: DataBase A
Patch backed out, and new combined version attached.
---
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Alternatively we could make them local to any block that contains an
> >> EXCEPTION
Neil Conway <[EMAIL PROTECTED]> writes:
> The second RAISE will report "successful completion". Is this the
> behavior we want?
No, certainly not --- I was just griping about the same thing.
> Is SQLERRM the best name for that variable? It seems a little obscure to me.
Oracle uses that name. W
Bruce Momjian wrote:
Patch applied.
This patch still needs work.
I added a documentation mention too.
I think the docs need more than just "these variables are set when an
exception is raised".
The patch current resets SQLSTATE and SQLERRM whenever a new block is
entered. So:
create f
Where are we on this? I do think it solves a problem that some are
having, and it seems it would detect a disconnected client and abort a
long running query.
I am not very excited about adding four more GUC variables, and I am
thinking we could just have it use the OS defaults and see if we need
Patch applied. I added a documentation mention too.
---
Pavel Stehule wrote:
> Hello,
>
> I updated patch to last changes plpgsql code. Patch contains changes for
> gram.y, pl_exec.c, plpgsql.h, regress/sql/plpgsql.sql an
Patch applied with adjustment --- the second part of your patch that
skips comparing the first byte seemed unnecessary. It seemed likely
to cause a cpu stall, so just doing the loop seemed faster.
Did you test if the second part of your patch actually caused a speedup?
-
Patch applied, with adjustment recommended by Tom.
> In order to be somewhat consistent and not too confusing, could we
> spell that as 'pg_strcasecmp(prev_wd, "TO") != 0' please?
---
Greg Sabino Mullane wrote:
[ There is t
I have applied the following patch to properly use parentheses around
macro arguments used in computations.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+
Euler Taveira de Oliveira wrote:
> This is translation updates for branchs 7.4 and 8.0.
Installed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
13 matches
Mail list logo
