Greg Sabino Mullane wrote:
Finally had a chance to sit down at look at this afresh, and I'm
pretty sure I've got all the kinks worked out this time. Apologies
for not attaching, but my mail system is not working well enough
at the moment. So, please try to break this patch:
Hello,
I used different format now. Documentation:
This patch is implementation of variables SQLERRM and SQLCODE for plpgsql
language. Variable SQLCODE contains five chars PostgreSQL Error Code,
SQLERRM contains relevant message last catched exception. All variables
are attached to
Alvaro Herrera wrote:
Well, apparently everyone says the system install is not portable and
the discussion stops there.
Well, who actually says that? I know that I was the one who actually
coded up the current avoid-system-install-at-all-cost behavior, but
only because we were too annoyed at
Berényi Gábor wrote:
The problem is something else.
Gives the same message.
Bruce Momjian pgman@candle.pha.pa.us ?rta:
Ber?nyi G?bor wrote:
Dear Bruce,
Didn't work:
Fatal bcc32.mak 169: No terminator specified for in-line file
operator
Look forward to hear of you again,
- You should write some regression tests for this functionality
- You should update the documentation
- Is there a reason why you've made the type of SQLCODE `text', rather
than integer?
Pavel Stehule wrote:
+ fict_vars_sect:
+ {
+ plpgsql_ns_setlocal(false);
+
Neil Conway [EMAIL PROTECTED] writes:
- Is there a reason why you've made the type of SQLCODE `text', rather
than integer?
The value isn't an integer ... which gets back to my point that this is
not compatible with Oracle's idea of SQLCODE and therefore we should *not*
use that name for it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* I think you should use PSQLexec instead of using PQexec directly. PSQLexec
is used by all \-commands and prints out queries with -E, which is very
helpful for debugging.
But these are not backslash commands, but almost directly analogous to
Tom Lane wrote:
I'm worried about whether this doesn't break the EXEC_BACKEND case.
Most of the code you've moved out isn't applicable to Windows, but
the fflushes probably are
Right, which is why the patch adds fflushes to the Unix implementation
of internal_forkexec(). On reflection, it is
The latest iteration.
I have added documentation and updated the expected output so that the
regression tests pass.
In addition, after looking at the various system view names, I decided
that 'pg_cache_dump' does not fit in nicely - so chose an more Pg
suitable name of 'pg_buffercache'. Some
Mark Kirkwood wrote:
+ tupledesc = CreateTemplateTupleDesc(NUM_BUFFERCACHE_PAGES_ELEM,
false);
+ TupleDescInitEntry(tupledesc, (AttrNumber) 1, bufferid,
+
INT4OID, -1, 0);
+
Neil Conway [EMAIL PROTECTED] writes:
Mark Kirkwood wrote:
+TupleDescInitEntry(tupledesc, (AttrNumber) 5, relblockbumber,
+
NUMERICOID, -1, 0);
I think this should be an int4, not numeric.
needs spell check too
Greg Sabino Mullane wrote:
* You have not yet implemented a way to savely put \reseterror
in .psqlrc. I previously suggested an AUTO setting (additional
to ON/OFF) that disables \reseterror when reading from a non-tty.
So putting \reseterror AUTO in ..psqlrc would be save.
Hmm...I suppose we could
Tom Lane wrote:
Perhaps OID would be a good choice even though it's horribly wrong on
one level.
Either that or add unsigned numeric types to PG :-)
I would rather see this as a contrib module.
I don't really have an opinion either way. Does anyone else have
thoughts on this?
There has been
Michael Paesold [EMAIL PROTECTED] writes:
I do think so. In it's current state, would you yourself put \reseterror in
your .psqlrc? Or even an /etc/psqlrc?
It would break all my scripts that must either succeed or fail -- now they
will produce garbage in my databases when something goes
14 matches
Mail list logo
