Tom Lane wrote:
[EMAIL PROTECTED] writes:
Another approach would have been to make libpq_gettext() preserve errno.
That seems like a far easier, cleaner, and more robust fix than this.
Provided that either:
(a) the C standard has added a sequence point between the arguments in a
function
Tom Lane wrote:
The gettext function does not modify the value of the global errno
variable. This is necessary to make it possible to write something like
printf (gettext (Operation failed: %m\n));
which is pretty much what I expected to find. Ergo, this entire
[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
Bruce Momjian wrote:
Bruce Momjian wrote:
This also adds a full_page_writes GUC to turn off page writes to WAL.
Some people might not want full_page_writes.
Fsync linkage removed, patch attached and applied.
...
+ When this option is on, the productnamePostgreSQL/ server
+ writes
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]
Neil Conway wrote:
Per C99 6.5.2.2.10, a sequence point occurs between the evaluation of
the arguments to a function and the call of the function itself.
Therefore a sequence point occurs before the call to libpq_gettext(). So
ISTM having libpq_gettext() preserve errno should work.
In C99,
[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
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 06 July 2005 04:11
To: Tom Lane
Cc: Dave Page; Christopher Kings-Lynne; Robert Treat; Dawid
Kuroczko; Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [HACKERS] [PATCHES] Dbsize backend
[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
Neil Conway [EMAIL PROTECTED] writes:
Right; my interpretation is that the sequence point before function
call rule applies recursively. So in c(a(...), b(...)), there are in
fact three sequence points, which precede the calls of a, b, and c.
Shouldn't that be sufficient to ensure that the
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.
Michael Paesold wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
This also adds a full_page_writes GUC to turn off page writes to WAL.
Some people might not want full_page_writes.
Fsync linkage removed, patch attached and applied.
...
+ When this option is on, the
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
The attached patch moves a plperl sanity check into the correct
position. Performing the check in the existing position allows the call
to go through to perl first, possibly resulting in a SEGV.
cheers
andrew
Index: plperl.c
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
Neil Conway [EMAIL PROTECTED] writes:
I wonder if there is any point introducing the concept of an
exception variable in the first place. What does it buy us over simply
using a string?
Not a lot really, except for keeping things similar to the Oracle way of
doing it ... but that's a
I built the v8.0.3 product from postgresql-8.0.3-1PGDG.src.rpm on
RedHat9 (I'm thinking the source RPM for RH9 should not have exactly the
same name as the FC3 version, since they are different files). When I
tried to roll it into an RPM CD builder transaction, I got 'RPM
dependency errors':
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,
exception variable in the first place. What does it buy us over simply
using a string? In other words, if we allowed the syntax:
RAISE LEVEL [ opt_sqlstate ] 'fmt' [, expr ... ]
where `opt_sqlstate' is either empty, a T_WORD we find in the table of
predefined condition names, or an
Neil Conway [EMAIL PROTECTED] writes:
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
This would require promoting all the options for LEVEL into fully
reserved words. You really can't get around the fact that you need
something pretty identifiable to terminate the expression.
It might work to require parentheses:
RAISE LEVEL ( sqlstate expression ), 'fmt' [, ...]
Pavel Stehule [EMAIL PROTECTED] writes:
if I use registered sqlstate, plpgsql knows text message.
No, it does not. I already pointed out that tying a single error
message to a SQLSTATE is unreasonable, because that's not how the
SQL committee intended SQLSTATEs to be used. I haven't looked at
On Wed, 6 Jul 2005, Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
if I use registered sqlstate, plpgsql knows text message.
No, it does not. I already pointed out that tying a single error
message to a SQLSTATE is unreasonable, because that's not how the
SQL committee intended
I really don't like the idea of introducing a new concept into the
language (exception variables) to resolve some ambiguous syntax. It
would be another matter if exception variables actually provided
something that strings do not...
In this time e.variables does it - only holds
So, my co-workers chided me mercilessly to get the -contrib RPM working
as well; so the full patch is now attached.
BTW, I did search the archive and this problem did not stick out; but it
could be my crummy reference skills. And, no, I didn't read all 3500
emails since the v8.0.3 release.
Mark Kirkwood wrote:
I did a few cleanups on the last patch. Please examine this one instead.
The changes are:
1. Add documentation for pg_datum_length builtin.
2. Correct some typos in the code comments.
3. Move the code in toastfuncs.c to varlena.c as it is probably the
correct place.
Mark Deric [EMAIL PROTECTED] writes:
So, my co-workers chided me mercilessly to get the -contrib RPM working
as well; so the full patch is now attached.
I think this overlaps or may be redundant with the patch that Peter E.
recently proposed; have you been following the thread about buildfarm
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
Per Andrew (he is having email problems):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=viperdt=2005-07-07%2001:10:01
Joshua D. Drkae
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
Neil Conway wrote:
Bruce Momjian wrote:
+ /* + * Return the length of a datum, possibly compressed
+ */
+ Datum
+ pg_column_size(PG_FUNCTION_ARGS)
+ {
+ Datumvalue = PG_GETARG_DATUM(0);
+ intresult;
+ + /*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
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
Neil Conway wrote:
elog(ERROR) is usually used for can't happen errors; also, the usual
error message in this scenario is cache lookup failed [...]. Perhaps
better to use get_typlen() here, anyway.
I have attached a little
Alvaro Herrera wrote:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
Neil Conway wrote:
elog(ERROR) is usually used for can't happen errors.
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way.
Alvaro Herrera [EMAIL PROTECTED] writes:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way.
I am, because it gives useless messages to the translators to
Neil Conway wrote:
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
Patch applied. Thanks.
---
Mark Kirkwood wrote:
Alvaro Herrera wrote:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
Neil Conway wrote:
elog(ERROR) is usually used for can't happen errors.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way.
I am, because it gives useless messages
Joshua D. Drake wrote:
Per Andrew (he is having email problems):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=viperdt=2005-07-07%2001:10:01
Thanks, fixed (I hope).
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610)
39 matches
Mail list logo
