Neil Conway wrote:
This patch reduces the size of the message header used by statistics
collector messages, per recent discussion.
Applied.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
This patch refactors away some duplicated code in the index AM build
methods: they all invoke UpdateStats() since they have computed the
number of heap tuples, so I created a function in catalog/index.c that
each AM calls. This is per earlier discussion (it was included in the
GiST patches I
John Hansen wrote:
Even more so if the 'currval(void) called before nextval(seq_name)'
error message could be supressed by a GUC variable and return 0
instead.
I don't think that's a good idea at all. It seems unnecessary, it
complicates the definition of the operation, and worse, 0 is a valid
Neil Conway wrote:
This patch makes some minor style cleanups to contrib/btree_gist: remove
the extern keyword for function definitions, reorganize some
PG_GETARG_XXX() usage, and similar.
Applied.
-Neil
---(end of broadcast)---
TIP 7: don't forget
Andrew Dunstan wrote:
I have just been alerted to a bug in the 8.0 handling of embedded
newlines in CSV data. Basically it barfs on consecutive newlines. The
attached patch for 8.0 appears to fix it. The bug isn't present in the
HEAD branch, and I'm wondering if we should not backpatch the HEAD
Andrew Dunstan wrote:
regression patch against 8.0 branch attached.
The tiny patch has been applied to REL8_0_STABLE, and the regression
test patch has been applied to both REL8_0_STABLE and HEAD. Thanks for
the patches.
-Neil
---(end of
Qingqing Zhou wrote:
***
*** 1,7
/*-
*
* getusage.c
! * 64-bit versions of fseeko/ftello()
*
* Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
* Portions Copyright
Neil Conway wrote:
This is an updated version of the GiST patch I posted a few months ago.
Attached is a revised version. This update fixes some newly-added bugs
in mark and restore (I forgot to save and restore the current buffer),
and replaces two ReleaseBuffer() + ReadBuffer() pairs
Patch applied.
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
BTW, this idiom occurs a few times:
if (BufferIsValid(buf))
{
ReleaseBuffer(buf);
buf = InvalidBuffer;
}
I'd leave it as-is; ISTM to be more easily understandable than the
alternatives you suggest
Patch applied.
Tom Lane wrote:
One objection: I think the GiST amproc numbers (GIST_CONSISTENT_PROC
and friends) *are* part of the API and should be in the public header,
even if they happen not to be used by any C code at the moment.
Ok, I've moved these back to gist.h
GISTNStrategies seems
Dennis Bjorklund wrote:
+ Datum
+ lastval(PG_FUNCTION_ARGS)
+ {
+ Relation seqrel;
+ int64 result;
+
+ if (last_used_seq == NULL) {
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg(nextval have not been used in the current session)));
+ }
has not
Abhijit Menon-Sen wrote:
Ah. I misunderstood the comment before the failing opr_sanity test.
Here's an updated patch, which also adds some regression tests.
Thanks, applied with a few tweaks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched
This patch removes a bunch of no-longer-necessary manual pfree() calls
from the implementation of GiST methods in contrib/ modules.
Barring any objections, I'll apply this tomorrow.
-Neil
Index: contrib/btree_gist/btree_bit.c
===
Neil Conway wrote:
This patch removes a bunch of no-longer-necessary manual pfree() calls
from the implementation of GiST methods in contrib/ modules.
Applied.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Andrew Dunstan wrote:
While building some better plperl tests today I discovered a horrid bug
(which I regret to say is my fault), present in both 8.0 and HEAD
branches
BTW, in future it would be good to specify the consequences of the bug
(i.e. beyond it is horrible), so committers who
ITAGAKI Takahiro wrote:
--- 622,628
for (i = 0; i (sizeof(DDLAFTERs) / sizeof(char *)); i++)
{
res = PQexec(con, DDLAFTERs[i]);
! if (strncmp(DDLAFTERs[i], drop, 4) PQresultStatus(res) !=
PGRES_COMMAND_OK)
{
ITAGAKI Takahiro wrote:
But this code seems to be an idiom,
Check the result, but drop commands may be fail.
Drop commands might be added to DDLAFTERs some time, so we may leave it.
Possibly, but I think checking for something that cannot occur is
confusing to the reader (and besides, it is
Tom Lane wrote:
psql, pg_dump, etc allow password specification from stdin and from
.pgpass, never on the command line. There is a reason why they are all
designed like that. pg_autovacuum hasn't been studied carefully enough
I guess, because we should never have let a security hole like this
Neil Conway wrote:
I think the reason there is at least some value in having this switch
for pg_autovacuum is that pg_autovacuum is almost exclusively used in a
situation in which the password can't be specified on the command-line
Sorry, thinko: I meant interactively via the terminal.
-Neil
Qingqing Zhou wrote:
On a separate matter, can anyone please explain me how this piece of code
works:
/* no free elements. allocate another chunk of buckets */
if (!element_alloc(hashp, HASHELEMENT_ALLOC_INCR))
return NULL; /* out of memory */
element_alloc() in fact uses
Tom Lane wrote:
The question at hand is whether we want to support an obvious security
hole. The argument that some people will not care applies with at
least as much force to psql or pg_dump, which at least have the grace
to not hang around and advertise their command-line parameters forever.
Tom Lane wrote:
That test is a no-op in the case where hashp-alloc in fact points to
palloc. But it doesn't always point there --- see shmem_alloc.
Perhaps it would be a net win to change ShmemAlloc() to elog(ERROR) on
out-of-memory? A fair few of the ShmemAlloc() call sites don't bother to
Tom Lane wrote:
I don't offhand know of any Unix platforms where they cannot be found
out
I don't know which platforms it is secure/insecure on, but I can
certainly imagine secure systems where ps(1) data in general is viewed
as sensitive and thus not made globally visible.
My inclination
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I don't know which platforms it is secure/insecure on, but I can
certainly imagine secure systems where ps(1) data in general is viewed
as sensitive and thus not made globally visible.
It's imaginable, but can you point to any real
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
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?
Applied to HEAD. Thanks
Bruce Momjian wrote:
Neil, I have added these item to the TODO list. Do you plan on applying
this?
No, I don't have any immediate plans to apply it, as unfortunately I
didn't see a performance win :-( It's also possible I'm just not
measuring the right workload, although I don't have time
Tom Lane wrote:
You seem to have also done a fair amount of unrelated hacking around.
What's the point of removing the distinction between check_ins and
check_upd functions?
I talked about this in an earlier message to -hackers: check_upd was
actually unused (check_ins was used for both
On Sun, 2005-05-29 at 21:06 -0400, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Hmm, I suppose -- if you prefer I can have check_ins called by the
INSERT trigger and check_upd called by the UPDATE trigger, which
probably makes more sense.
Yeah ... I thought it was doing
On Mon, 2005-05-30 at 02:52 -0400, Tom Lane wrote:
Some googling suggests so, eg
http://www.die.net/doc/linux/man/man2/open.2.html
Well, that claims that data is guaranteed to have been transferred,
but transferred to *where* is the question :) Transferring data to the
disk's buffers and then
On Sun, 2005-05-29 at 23:09 -0400, Tom Lane wrote:
Looks OK to me. Don't forget that the first of these should probably
include a catversion.h bump.
Both patches applied to HEAD, catversion bumped. Thanks for the
comments, Tom.
-Neil
---(end of
On Mon, 2005-05-30 at 11:24 -0400, Tom Lane wrote:
Wouldn't count on it :-(. One thing I'm particularly worried about is
buffer cache consistency: does the kernel guarantee to flush any buffers
it has that overlap the O_DIRECT write operation?
At least on Linux I believe the kernel guarantees
On Tue, 2005-05-31 at 13:07 +1200, Mark Kirkwood wrote:
I did some patches for 7.4 and 8.0 a while ago (attached) - while I do
not expect these to be applied
Right, I don't see a need to backport this.
is there somewhere for things like this to go?
Pg Foundry?
-Neil
On Wed, 2005-06-01 at 17:08 -0700, Mary Edie Meredith wrote:
I know I'm late to this discussion, and I haven't made it all the way
through this thread to see if your questions on Linux writes were
resolved. If you are still interested, I recommend read a very good
one page description of
On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
1) The patch includes 2 parallel parsing code paths. One is the regular COPY
path that we all know, and the other is the improved one that I wrote. This
is only temporary, as there is a lot of code duplication
Right; I really dislike the
On Thu, 2005-06-02 at 00:53 -0400, Alon Goldshuv wrote:
My thoughts were -- see how the responses are, and if people think
that this is a better way to go than replace the COPY parsing logic to
the new one.
If the new approach to parsing can handle all the cases that the old
approach can
On Sun, 2005-05-22 at 21:25 +0530, Abhijit Menon-Sen wrote:
I have attached the following seven patches to address this problem:
Does anyone with the skills to review this (i.e. someone other than me)
have any comments on this patch?
Otherwise I'll apply it in a day or two.
-Neil
On Sun, 2005-05-08 at 19:00 +0200, Dennis Bjorklund wrote:
Here is a small patch that implements a function lastval() that
works just like currval() except that it give the current
value of the last sequence used by nextval().
Have you had a chance to respin this patch per my earlier comments
Pavel Stehule wrote:
http://www.techonthenet.com/oracle/functions/add_months.htm
http://www.techonthenet.com/oracle/functions/last_day.htm
http://www.techonthenet.com/oracle/functions/next_day.htm
http://www.techonthenet.com/oracle/functions/months_between.htm
Are these functions useful enough
Bruce Momjian wrote:
Could we do your NOLOGGING automatically in COPY if we test to see if
anyone else is connected to our current database?
That seems pretty fragile -- what happens if someone connects after the
COPY has started? Considering that many COPY operations can take many
minutes
If you're busy, I can clean this up and apply it.
I wonder if it would be better to have lastval() return the last value
returned by nextval() or setval() for the current session, regardless of
any intervening DROP SEQUENCE commands. This would simplify the
implementation (we can just store
Abhijit Menon-Sen wrote:
Could someone who likes this idea please write the documentation for it?
Dennis' original patch includes documentation updates and a description
of lastval():
http://archives.postgresql.org/pgsql-patches/2005-05/msg00059.php
I'd really like to see a concise,
Tom Lane wrote:
This definition is OK with me ... so long as it still includes the
phrase an error occurs if no nextval or setval has occurred in the
current session. However it seemed that a number of people asking
for the feature wanted some-random-default to be returned instead.
Right --
Tom Lane wrote:
I agree with that --- consider that you couldn't actually promise that
the sequence hadn't been dropped by the time the answer is returned,
anyway, unless you take out a lock on the sequence first. Which doesn't
seem like a behavior that is wanted here.
The only objection I
Tom Lane wrote:
I still find the grammar changes to be an ugly kluge --- it should be
possible to do this without introducing bogus nonterminals.
The scope-local variables need to be added to the namespace by the time
that we parse the WHEN clauses. I can see two ways to do that: adding a
Tom Lane wrote:
A nonterminal that is not intended to represent any real input, ever,
is just plain weird.
If you say so... PL/PgSQL already uses such a beast, though: the lno
nonterminal, for example.
Not at all. The right way to do this, I think, is for the mid-rule
action to palloc the
Neil Conway wrote:
This patch removes some old code from libpq that implements a URI-like
syntax for database connection parameters. It has been inside an #ifdef
NOT_USED block since 2001 or so and is marked as broken, so I don't
think it is likely to be rehabilitated any time soon.
Applied
Neil Conway wrote:
Attached is a patch that implements this. This adds checking for most of
the call sites of strdup(), malloc(), PQmakeEmptyPGresult(),
pqResultAlloc(), and pqResultStrdup() in libpq. Barring any objections,
I'll apply this to HEAD tomorrow.
Applied. Thanks for the report
Per discussion on -hackers, this patch changes psql's expanded output
mode to only affect the presentation of normal query results, not the
output of psql slash commands. Documentation updated. I also made some
unrelated minor psql cleanup.
Barring any objections I'll apply this later today
This makes a few improvements to PL/PgSQL's ability to dump the parse
tree of a compiled function (via #option dump, which is currently
undocumented):
- functions - function's
- dump INTO target for EXECUTE
- don't dump ELSE clause for IF statements if the ELSE is empty (since
we have an
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
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
Neil Conway wrote:
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.
Applied.
-Neil
---(end of broadcast)---
TIP 6: Have
This patch makes various cosmetic improvements to the timezone code:
remove the use of the register qualifier, make some function declaration
syntax a bit more consistent, etc.
I'll apply this later today, barring any objections.
-Neil
Index: src/timezone/ialloc.c
Tom Lane wrote:
I think mostly what you are doing here is causing code drift from the
upstream zic code. I don't think that's a very good idea, since we
do need to be able to track and apply bug fixes from them from time
to time ...
Why run pgindent on the timezone code, then? That seems
Tom Lane wrote:
Well, it's certainly hopeless to expect patch to fix it :-(. But the
further the code drifts the harder it gets to compare manually.
Sure, but I don't see how removing a few register qualifiers and so
forth is going to make the slightest difference to a manual comparison.
If
The Coverity tool picked up some rather bizarre code in _tarGetHeader in
pg_backup_tar.c:
(1) The code doesn't initialize `sum', so the initial does the checksum
match? test is wrong.
(2) The loop that is intended to check for a null block just checks
the first byte of the tar block 512
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
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
Alvaro Herrera wrote:
This trivial patch removes an unused variable, this time in
utils/init/postinit.c
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Magnus Hagander wrote:
This patch removes Kerberos version 4 support from the backend and
libpq.
Applied, thanks.
Bruce, can you mark the Remove krb4 TODO item as finished? Thanks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our
Petr Jelínek wrote:
I am bit confused now because I am no really sure if it's intended to be
this way or not - 8.0 behaviour was to report numbackends when stats
were on, now it reports numbackends when stats_row_level is true.
Yeah, this is a bug. Attached is a fix. I'll apply this to HEAD
Tom Lane wrote:
I looked at this but did not actually see the code path that requires
forcing creation of the per-DB entry right at this spot. The HASH_FIND
calls for this hashtable seem to all happen on the backend side not the
collector side. Can you explain why we need this?
Yeah, I
Tom Lane wrote:
Right. So do we care whether the collector has the right number?
Not at present; n_backends is not read/written by the stats collector
itself, it is just in the hash table for the convenience of backends who
read in the stats file.
Or should we push the responsibility for
Tom Lane wrote:
I'm still missing what the exact bug fix is here.
The bug is:
- a backend starts up and sends the collector a BESTART message. For the
sake of clarity, suppose that the backend is the first and only backend
connected to its database.
- the stats collector receives the
The attached patch fixes a theoretical memory leak in libpq: if the
second malloc() fails due to OOM, the memory returned by the first
(successful) malloc() will be leaked.
Barring any objections I'll apply this tomorrow.
Per report from EnterpriseDB's Coverity analysis.
-Neil
Index:
Tom Lane wrote:
Since both allocations are only transient within this routine, there's
a simpler more effective solution, which is to only do one malloc in
the first place
Yeah, true. Attached is a revised patch -- committed to HEAD.
-Neil
Index: src/interfaces/libpq/fe-auth.c
Attached is a trivial improvement to ecpg's pgtypeslib: (1) `pstr' must
be non-NULL in this function, so no need to check for it (2) we should
check the return value of pgtypes_strdup(). Patch from Eric Astor at
EDB, with slight cleanup by myself, to fix a Coverity report.
Barring any
This patch adds some missing error handling to PGTYPESnumeric_div() in
ecpg's pgtypeslib: (1) we need to check the return value of sub_abs()
(2) we need to check the return value of 4 calls to digitbuf_alloc().
Per Coverity static analysis by EDB.
Barring any objections I'll apply this to CVS
Neil Conway wrote:
This patch adds some missing error handling to PGTYPESnumeric_div() in
ecpg's pgtypeslib: (1) we need to check the return value of sub_abs()
(2) we need to check the return value of 4 calls to digitbuf_alloc().
Applied.
-Neil
---(end of broadcast
Neil Conway wrote:
Attached is a trivial improvement to ecpg's pgtypeslib: (1) `pstr' must
be non-NULL in this function, so no need to check for it (2) we should
check the return value of pgtypes_strdup(). Patch from Eric Astor at
EDB, with slight cleanup by myself, to fix a Coverity report
Hi,
BTW, the Postgres convention is to submit patches in context diff format
(diff -c).
Satoshi Nagayasu wrote:
+ while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
+ {
+ HeapTuple newtup = heap_copytuple(tuple);
+ Form_pg_trigger pg_trigger =
Bruce Momjian wrote:
Patch applied. Thanks.
Should either or both of these patches be applied to back branches?
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Andrew Dunstan wrote:
In the course of looking into Larry's buildfarm woes, I found that
Unixware needs this patch on HEAD to build correctly
Thanks -- I already applied an equivalent fix to HEAD.
-Neil
---(end of broadcast)---
TIP 6: Have you
Marko Kreen wrote:
Please use following updated patch instead.
It implements utf8 conversion, fixes couple of bugs and has
many code and comment cleanups.
The regression tests don't pass on my box. With the default Makefile,
there are a lot of errors WRT no strong random source. After
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
I'll review and apply this in the next day or so.
Next ToDo (needs discussion):
+ Optional message in raise stmt for user's or system exception
raise exception division_by_zero;
+ Possibility
This patch silences a GCC 4.0 warning about a potentially-uninitialized
variable in pl_comp.c, and makes some minor associated cleanups. Barring
any objections I'll apply this to HEAD tomorrow.
-Neil
Index: src/pl/plpgsql/src/pl_comp.c
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
That is not the latest version of Marko's patch. But in any case, the
patch is not yet ready for application:
http://archives.postgresql.org/pgsql-patches/2005-07/msg00077.php
-Neil
[EMAIL PROTECTED] wrote:
(a) the C standard has added a sequence point between the arguments in a
function call, which AFAIK wasn't there before, or the sequence point was
there all along (and the compiler implements it);
Per C99 6.5.2.2.10, a sequence point occurs between the evaluation of
Tom Lane wrote:
- should work for UPDATE and DELETE too
And probably INSERT ... SELECT as well.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Does anyone know what the situation is in C89, or whatever the applicable
standard is?
[ *looks* ]
The text is the same in both versions:
http://dev.unicals.com/papers/c89-draft.html#3.3.2.2
The order of evaluation of the function designator, the arguments, and
[EMAIL PROTECTED] wrote:
That is pretty much what I remember hearing at the time.
A well-known way to trigger undefined behaviour is x++=x++; because
there is no sequence point between the two side effects. Try it: gcc will
give you a stern warning. Given that there is no sequence point
Tom Lane wrote:
I think this is all irrelevant language-lawyering; jtv spotted the true
problem which is that we do not protect errno during the *first* call of
libpq_gettext.
I think you're missing the point. Obviously the current code is wrong,
the debate is over the best way to fix it.
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
Attached is a revised patch. I haven't looked at the documentation
changes yet (more work is needed I believe) or some of the error message
text.
I was originally hoping to make exception variables a
This patch fixes the following issues in ECPGstore_input():
- strlen() was invoked on the NULL pointer for the first iteration of
the loop (line 875, 923, 966, 1009)
- `nval' is freed for every iteration of the loop at 864, but only
initialized once outside the loop, resulting in potential
Tom Lane wrote:
I think it is a bad idea, if not actually impossible, to have an
expression for sqlstate with no separating syntax before the 'fmt';
especially not if you'd like to also allow an expression for the 'fmt'.
I don't actually see much of a need to allow 'fmt' to be an expression,
Tom Lane wrote:
RAISE NOTICE '12' !! '345', ...
Is !! an infix operator (using both strings as arguments) or a postfix
operator (in which case '345' is the format)?
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error
Bruce Momjian wrote:
+ /*
+ * Return the length of a datum, possibly compressed
+ */
+ Datum
+ pg_column_size(PG_FUNCTION_ARGS)
+ {
+ Datum value = PG_GETARG_DATUM(0);
+ int result;
+
+ /* fn_extra stores the fixed column length, or
Mark Kirkwood wrote:
I didn't performance test it, but the idea of hammering the catalogs for
each value to be processed seemed a bad thing.
Well, the syscache already sits in front of the catalogs themselves. I'd
be curious to see what the performance difference actually is...
-Neil
Gavin Sherry wrote:
This patch removes dead code from redo_dbase().
Barring any objections, I'll apply this tomorrow.
I've removed XLOG_DBASE_CREATE_OLD and XLOG_DBASE_DROP_OLD from the header
as well but have not changed the values of XLOG_DBASE_CREATE and
XLOG_DBASE_DROP so as to avoid the
Michael Fuhr wrote:
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Barring any objections, I'll apply this tomorrow.
-Neil
---(end of
Gavin Sherry wrote:
This patch removes dead code from redo_dbase(). The code processes
CREATE/DROP DATABASE recovery records which are of types
XLOG_DBASE_CREATE_OLD and XLOG_DBASE_DROP_OLD. We do not create such
records.
Applied with additional fixes (you forgot to remove the reference to the
Michael Fuhr wrote:
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 9: In versions
Neil Conway wrote:
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error condition), or a TEXT
variable. If users need to throw a sqlstate that is derived from a SQL
expression, they can always assign to a TEXT variable and then specify
Pavel Stehule wrote:
ok, but don't forget, please, on exception part.
What do you mean?
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
Per EDB's Coverity analysis, runtimeKeyInfo is only non-NULL if
econtext is also non-NULL, so we can eliminate a conditional on the
former by moving it inside an if block for the latter. Per discussion
of earlier similar changes, this is not for performance reasons but for
code clarity.
Pavel Stehule wrote:
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
I'm sorry, but I'm still not sure what you mean.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
[EMAIL PROTECTED] wrote:
Thank you, that would answer the question. There is no also about it;
it's exactly what I was asking all along. The conclusive answer for us
would be in the C89 standard of course, where (at least in the draft that
Neil quoted) I haven't been able to find anything like
Bruce Momjian wrote:
Where are we on this patch? Is there something to apply?
Not at the moment. I believe we have agreed that it would be better to
remove the concept of exception variables and just use strings, but I
haven't implemented this yet. I'm happy to do that, but I might not get
401 - 500 of 833 matches
Mail list logo
