Would you send over the patch --- it was missing.
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >
> >Applied with some editorializing. In particular, I don't believe the
> >original did the right thing with (a - (b - c)).
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Well, to me it's not well-known that floating-point addition is not
> associative, do I need to re-learn my math?
regression=# select (1.0::float8 + (-1.0::float8)) + 1.0e-20::float8;
?column?
--
1e-20
(1 row)
regression=# select 1.0::floa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I didn't like the functions ending in _ext. I renamed them to _pp for
> > pretty print. Patch attached and applied.
>
> Seems to be shy a catversion bump; since you have just made an
> incompatible change in the internal-function-na
On Thu, 31 Jul 2003 16:30:17 +0200, Andreas Pflug
<[EMAIL PROTECTED]> wrote:
>Well, to me it's not well-known that floating-point addition is not
>associative
This is a case of theory vs. practice mismatch: In theory addition is
associative, in practice there is only limited storage available fo
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Well, to me it's not well-known that floating-point addition is not
associative, do I need to re-learn my math?
regression=# select (1.0::float8 + (-1.0::float8)) + 1.0e-20::float8;
?column?
--
1e-20
(1 row)
regression=#
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Now the patch is *really* appended :-)
And rejected. You cannot assume that an operator is commutative or
associative just because it has a name you think ought to be.
(For a counter-example, it's well known that floating-point addition
is not associati
Tom Lane wrote:
Now the patch is *really* appended :-)
And rejected.
Ok, the ckeck for node being the first child already does the trick for
standard l-t-r evaluation.
You cannot assume that an operator is commutative or
associative just because it has a name you think ought to be.
(For
Now the patch is *really* appended :-)
Tom Lane wrote:
Applied with some editorializing. In particular, I don't believe the
original did the right thing with (a - (b - c)).
Oops, missed that case...
But now, we have (a + ( b + c)) again.
A patch that removes parentheses for + and * is appende
Tom Lane wrote:
Applied with some editorializing. In particular, I don't believe the
original did the right thing with (a - (b - c)).
Oops, missed that case...
But now, we have (a + ( b + c)) again.
A patch that removes parentheses for + and * is appended.
Regards,
Andfdsa
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I didn't like the functions ending in _ext. I renamed them to _pp for
> pretty print. Patch attached and applied.
Seems to be shy a catversion bump; since you have just made an
incompatible change in the internal-function-names array, one is needed.
B
Didn't Tom already apply that???
Chris
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: "Andreas Pflug" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, July 31, 2003
Patch applied, modified by Tom and myself.
---
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >Andreas, looks good, but I need a diff -c, context diff.
> >
> >
> >
> Hi Bruce,
> I intentionally only attached only non-con
I didn't like the functions ending in _ext. I renamed them to _pp for
pretty print. Patch attached and applied.
---
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > I recoded the stuff as Tom recommended, le
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I recoded the stuff as Tom recommended, leaving the non-pretty version
> function names as they used to be, inventing new pg_get__ext
> functions for the extended stuff, and pushing the code down into
> pg_get__worker functions when needed. We
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
+ int prettyFlags = !PG_ARGISNULL(1) && PG_GETARG_BOOL(1) ? PRETTYFLAG_PAREN|PRETTYFLAG_INDENT : 0;
Since the pg_proc entries are all marked strict, it's unnecessary for
you to write any ARGISNULL checks.
Yeah you're ri
Andreas Pflug <[EMAIL PROTECTED]> writes:
> + int prettyFlags = !PG_ARGISNULL(1) && PG_GETARG_BOOL(1) ?
> PRETTYFLAG_PAREN|PRETTYFLAG_INDENT : 0;
Since the pg_proc entries are all marked strict, it's unnecessary for
you to write any ARGISNULL checks.
regar
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom, how do I pass PG_FUNCTION_ARGS to another function, while adding a
new parameter?
I wouldn't. Do the PG_GETARGS in the wrapper, and have the called
function take a normal C parameter list.
So I
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, how do I pass PG_FUNCTION_ARGS to another function, while adding a
> > new parameter?
>
> I wouldn't. Do the PG_GETARGS in the wrapper, and have the called
> function take a normal C parameter list.
So I need to wrappers for ea
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, how do I pass PG_FUNCTION_ARGS to another function, while adding a
> new parameter?
I wouldn't. Do the PG_GETARGS in the wrapper, and have the called
function take a normal C parameter list.
regards, tom lane
-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are these illustrating a problem with the function definition, or is it
> > happening because it is the first time we are calling the same function
> > with one and more than one parameter?
>
> The function definition is broken. Whil
OK, I am working on that now. I suspected that was the solution.
I met the patch author at LinuxTag and he mentioned he wasn't familiar
with the backend code yet, so I am glad to do the work to get this done
correctly.
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are these illustrating a problem with the function definition, or is it
> happening because it is the first time we are calling the same function
> with one and more than one parameter?
The function definition is broken. While it could be fixed (by
expl
I am seeing the following regression failures from the patch to allow
pretty printing pg_get_*def functions.
Are these illustrating a problem with the function definition, or is it
happening because it is the first time we are calling the same function
with one and more than one parameter?
In fa
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >Andreas, looks good, but I need a diff -c, context diff.
> >
> >
> >
> Hi Bruce,
> I intentionally only attached only non-context diffs because the patch
> is about 50 % size of the original file. Now, here's the same as context
> diff.
I under
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Andreas Pflug wrote:
> Bruce Momjian wrot
Bruce Momjian wrote:
Andreas, looks good, but I need a diff -c, context diff.
Hi Bruce,
I intentionally only attached only non-context diffs because the patch
is about 50 % size of the original file. Now, here's the same as context
diff.
Regards,
Andreas
Index: pg_proc.h
===
Andreas, looks good, but I need a diff -c, context diff.
---
Andreas Pflug wrote:
> Hi Bruce,
> so here's the complete patch against the current cvs.
>
> Description:
> The attached patches will add
>pg_get_ruledef(oid,
Hi Bruce,
so here's the complete patch against the current cvs.
Description:
The attached patches will add
pg_get_ruledef(oid, bool)
pg_get_viewdef(text, bool)
pg_get_viewdef(oid, bool)
pg_get_indexdef(oid, int4, bool)
pg_get_constraintdef(oid, bool)
pg_get_expr(text, oid, bool)
If the
Sorry I am getting to this patch late. I know you posted a newer
version, but this one has a better description.
I am uncertain if we are over-engineering the interface by having three
ways to control the output. Is that valuable? If it is, fine, but if
it isn't, the extra code just adds to con
Is there a problem about the archive?
I posted this addition to the patch on July 2, and received it over the
patches mailing list. Still, it doesn't appear in cvs, in "unapplied
patches" or in the mailing list archive! So although that message made
its way through the list server, it didn't end
The patch has been updated, the attached files will replace my previous
post completely against ruleutils.c 1.143.
pg_get_indexdef is extended to take 3 arguments:
pg_get_indexdef(index_oid, columnNr_int, prettyOpt_int)
Still, pg_get_indexdef(oid) will deliver the same result as it used to be.
Th
The attached patches will add
pg_get_ruledef(oid, int)
pg_get_viewdef(text, int)
pg_get_viewdef(oid, int)
pg_get_indexdef(oid, int)
pg_get_constraintdef(oid, int)
pg_get_expr(text, oid, int)
If the last parameter "pretty-print" is 0, these function will return
the same result as
32 matches
Mail list logo
