> I don't see an easy way to get around this, though, and it's not too
> concerning. Amusingly it does completely break the SQLSTATE and SQLERRM
> tests we added a few days ago :)
Yes, it's true. But with simple plpgsql parser isn't possible expect
miracles :). I think so there is some space f
Pavel Stehule wrote:
I did trivial patch which eliminate limit raise command.
In thinking about this some more, it would be nice to be able to use
exec_eval_expr() to reduce expression evaluation overhead for simple
RAISE parameters. It is easy enough to refactor the current
exec_eval_expr()
The character-code conversion from EUC_JP to SJIS is executed by
converting two stages. The first stage is conversion from EUC_JP to MIC.
The next stage is conversion from MIC to SJIS. (Conversion from SJIS to
EUC_JP is also similar.)
It is not so efficient, because it is necess
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, one regression is that an undefined variable in the RAISE list is
> no longer a compile-time error:
> ...
> I don't see an easy way to get around this, though, and it's not too
> concerning. Amusingly it does completely break the SQLSTATE and SQLERRM
> That doesn't bother me either, seeing that an undefined variable isn't
> detected at compile time anywhere else. However, fixing the SQLSTATE
> tests by removing them doesn't seem like a great solution ...
>
> > BTW, another easy improvement in this area is changing the RAISE format
> > string
Pavel Stehule <[EMAIL PROTECTED]> writes:
>> Ideas?
> only RAISE? Without parameters can be used only in block. It's same scope
> like SQLERRM and SQLSTATE.
OK, but what about the other problem --- throwing a non-default SQLSTATE
along with your custom error message?
> RAISE my_exception; --
> I would sort of have expected this to get done at the same time.
>
> Actually, the reason I didn't do something about RAISE in 8.0 was that
> I thought we should reconsider the whole design of the statement: it
> desperately needs to be fixed so that you can specify the SQLSTATE to
> be thrown,
Pavel Stehule <[EMAIL PROTECTED]> writes:
> declare myexcept exception = 'x';
> begin;
> assoc(myexcept, 'my message % % %');
> raise myexcept, param1, param2, ...
Our experience in writing the backend is that hard-wiring a single error
message text for a SQLSTATE code is the wrong
On Mon, 13 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> >> Ideas?
>
> > only RAISE? Without parameters can be used only in block. It's same scope
> > like SQLERRM and SQLSTATE.
>
> OK, but what about the other problem --- throwing a non-default SQLSTATE
> along with y
> Our experience in writing the backend is that hard-wiring a single error
> message text for a SQLSTATE code is the wrong thing. The SQLSTATE codes
> are relatively coarse-grained (which is usually the right thing from the
> perspective of an application trying to match a SQLSTATE) and there is
Pavel Stehule <[EMAIL PROTECTED]> writes:
> Next problem, visibility custom exceptions. When I define exception
> variable I can't rethrown exceptions outside block when is defined. What
> is outside - some custom exception?
I don't think this is an issue. A custom exception is really just a
na
> > This patch makes it possible to use the full set of timezones when
> > doing "AT TIME ZONE", and not just the shorlist previously
> available.
>
> > Docs updates forthcoming assuming this approach is
> considered good ;-)
>
> Looks reasonable to me, please supply docs.
Great. Here is a do
Currently, nonfatal warnings are not trapped (as they should be) by
plperl - the attached small patch remedies that omission, and adds a
small regression test for error and warning output - the new regression
input and expected output are in separate attached files.
cheers
andrew
Index: GN
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Currently, nonfatal warnings are not trapped (as they should be) by
> plperl - the attached small patch remedies that omission, and adds a
> small regression test for error and warning output - the new regression
> input and expected output are in sep
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Currently, nonfatal warnings are not trapped (as they should be) by
plperl - the attached small patch remedies that omission, and adds a
small regression test for error and warning output - the new regression
input and expected o
>
> I would also expect that matching is by SQLSTATE, that is if I write
>
> DECLARE foo EXCEPTION = '12345';
> ...
> RAISE ERROR foo, ...;
>
> then some outer block written as
>
> DECLARE bar EXCEPTION = '12345';
> ...
> EXCEPTION WHEN bar THEN ...
>
if we
Neil Conway wrote:
This makes a few improvements to PL/PgSQL's ability to dump the parse
tree of a compiled function
Applied.
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Tom Lane wrote:
That doesn't bother me either, seeing that an undefined variable isn't
detected at compile time anywhere else. However, fixing the SQLSTATE
tests by removing them doesn't seem like a great solution ...
Yeah, true, I can just invoke the function to trigger the undefined
variabl
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, the reason I didn't do something about RAISE in 8.0 was that
>> I thought we should reconsider the whole design of the statement
> The ensuing discussion on this sounds good to me; should I apply Pavel's
> RAISE patch now, or
[EMAIL PROTECTED] wrote:
> This update replaces the previous patch for the psql logfile option
>
> The print.c routine is also built into src/bin/scripts
>
> The ifdef USE_LOGFILE wrapper is to keep out compile errors when the
> routine is linked into programs other than psql
I have applied the
Per earlier discussion on pgsql-hackers[1], this patch changes the
implementation of hash join to attempt to avoid redundant work if either
of the join relations are empty. The logic is:
(1) if the inner relation's startup cost is less than the outer
relation's startup cost and this is not an
Tom Lane wrote:
But you had mentioned wanting to look at reducing overhead by using
exec_eval_expr(); were you intending to do that before committing?
I'm a bit busy with other matters at the moment, so I'll probably look
at it later. One question is whether we should make use of
exec_eval_ex
Neil Conway <[EMAIL PROTECTED]> writes:
> ... One question is whether we should make use of
> exec_eval_expr() by representing the RAISE parameter list as a list of
> expressions (each of which would likely be simple enough to evaluate via
> ExecEvalExpr()), or whether we want to extend exec_eva
Tom Lane wrote:
I'd lean to the former myself --- which actually does suggest that this
patch is not ready for application yet, because it banks on the
assumption that "x,y,z" should be treated as a single expression.
Attached is a revised patch that stores the RAISE parameters as a list
of ex
24 matches
Mail list logo
