>The only complaint I've seen in this thread that seems like a valid >deficiency is that RAISE can't deal with treating the error severity level >as a variable. But surely we should address that as a new RAISE feature, >not by inventing a SQL wrapper that will need to reproduce every existing >RAISE feature before it can think about solving anything new.
That seems like something independently useful.
fa If we're up for that the other thing I'd add is having raise ignore anything supplied by USING that's NULL, instead of treating it as an error. That would make it very easy to create a wrapper function that exposes the full capabilities of RAISE.
I don't think so ignoring NULL in RAISE statement is good idea (it is not safe). We can replace NULL by some string (like "NULL") by default. I am thinking about other possibilities.
1. some RAISE statement flag - but there was strong disagreement when I did it last time
2. some plpgsql GUC variables like plpgsq.raise_ignore_null
3. accept a function from this patch
Now, I am thinking so @3 is good option. It can be really useful as last rescue for other PL without possibility to raise rich PostgreSQL exception - currently PLPythonu, partially PLPerl (where are more issues), probably in others.
Regards
Pavel
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
From:
Kyotaro HORIGUCHI Date: Subject:
Re: Re: [HACKERS] Windows service is not starting sothere’s message in log: FATAL: "could not createshared memory segment “Global/PostgreSQL.851401618”: Permissiondenied”
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.
