Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Ah, got it, and I updated the patch to remove the commment about
> > "discrete".
>
> The page also says that 0^x is undefined when x is negative, not sure
> about that one but I don't see it in your patch.
That one was already handled:
Bruce Momjian wrote:
> Ah, got it, and I updated the patch to remove the commment about
> "discrete".
The page also says that 0^x is undefined when x is negative, not sure
about that one but I don't see it in your patch.
--
Alvaro Herrerahttp://www.CommandPrompt.
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > I have developed the attached patch which fixes 0 ^ 123.3.
> > >
> > > Did you actually read the wikipedia entry you cited?
>
> But that's about 0^0, not about 0^123.3. See th
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I have developed the attached patch which fixes 0 ^ 123.3.
> >
> > Did you actually read the wikipedia entry you cited?
But that's about 0^0, not about 0^123.3. See this other subsection:
http://en.wikipe
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have developed the attached patch which fixes 0 ^ 123.3.
>
> Did you actually read the wikipedia entry you cited?
Yes:
The evaluation of 0^0 presents a problem, because different mathematical
reasoning leads to different results.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have developed the attached patch which fixes 0 ^ 123.3.
>
> Did you actually read the wikipedia entry you cited?
Considering that 0::float8 ^ 0::float8 yields 1, making the numeric operator
do the same might not be completely unre
On Wed, 7 May 2008, Bruce Momjian wrote:
Patch attached that issues a warning.
This doesn't take into account the -F case and the warning isn't quite
right because of that as well. When I get a break later today I'll create
a new patch that handles that correctly, I see where it should go n
Brendan Jurd escribió:
> On Thu, Apr 17, 2008 at 7:27 AM, Alvaro Herrera wrote:
> > Thanks. I looked the patch over and did some minor changes. Modified
> > version attached.
>
> Cool, I had a look through your changes and they all seemed fine to
> me. In particular, moving the header comm
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your sub
Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Fri, 14 Mar 2008, Tom Lane wrote:
> >> Yeah, -s is only meaningful when given with -i. Maybe someday we ought
> >> to fix pgbench to complain if you try to set it at other times.
>
> > You have to pass -s in to the actual run if you'
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Surely psql computes the width of all cells before printing anything.
> >
> > It does, but if you have a value that has a tab, how do you know what
> > tab stop you are on because you don't know the final width of the
Richard Wang wrote:
> I expected 0 ^ 123.3 to be 0, but it reported error as follows
>
> postgres=# select 0 ^ 123.3;
> ERROR: cannot take logarithm of zero
>
> I find that there is a bug in numeric_power() function
> the function caculates a ^ b based on the algorithm e ^ (lna * b)
> as you see
On Thu, 2007-02-08 at 18:21 -0500, Bruce Momjian wrote:
> Where are we on this feature?
Any update, Bernd?
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgre
Attached patch adds some error checking to the thread locking stuff in
libpq. Previously, if thread locking failed for some reason, we would
just fall through and do things without locking. This patch makes us
abort() instead. It's not the greatest thing probably, but our API
doesn't let us pass ba
Tom Lane wrote:
> I looked over this patch and I think it still needs work.
Thanks for the thorough review. I'll be working on these problems soon.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 suppor
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Surely psql computes the width of all cells before printing anything.
> >
> > It does, but if you have a value that has a tab, how do you know what
> > tab stop you are on because you don't know the final width of the
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Surely psql computes the width of all cells before printing anything.
>
> It does, but if you have a value that has a tab, how do you know what
> tab stop you are on because you don't know the final width of the
> previous columns at that time, so
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > If you start counting every line from the start of the current column,
> > > it will align correctly regardless of the previous columns.
> >
> > At this stage you don't know the width of previous columns because you
>
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > If you start counting every line from the start of the current column,
> > it will align correctly regardless of the previous columns.
>
> At this stage you don't know the width of previous columns because you
> don't know if a very wide value is c
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Even if we knew the column position at output time, when we are doing
> > aligned column width computations, we don't know the width of the
> > previous columns so we would have no way to know how far the tab would
> > extend in the current column
Bruce Momjian wrote:
> Even if we knew the column position at output time, when we are doing
> aligned column width computations, we don't know the width of the
> previous columns so we would have no way to know how far the tab would
> extend in the current column.
If you start counting every lin
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have implemented the following patch which outputs tab as a tab. It
> > also assumes a tab has a width of 4, which is its average width:
>
> That pretty much completely sucks; it will undo all the hard work we've
> put into nice fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have implemented the following patch which outputs tab as a tab. It
> also assumes a tab has a width of 4, which is its average width:
That pretty much completely sucks; it will undo all the hard work we've
put into nice formatting of the output, beca
Cliff Nieuwenhuis wrote:
> On Tuesday 11 March 2008 11:41:35 Tom Lane wrote:
> > Cliff Nieuwenhuis <[EMAIL PROTECTED]> writes:
> > > I'm not sure how to ask this question. I have written a function, and
> > > with PostgreSQL 8.0.13 I can do a "\df+" and see something like this
> > > under Source C
Re-sending post as discussed with Bruce...
On Sun, 2008-03-23 at 12:45 -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Added to TODO:
> >
> > o Allow pre/data/post files when dumping a single object, for
> > performance reasons
> >
> > http://archives.pos
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Currently this loops through all the constraints for a relation (old
> behavior of MergeAttributesIntoExisting)... Do you think its worth
> adding a non-unique index to speed this up?
No. If we were to refactor pg_constraint as I mentioned earlier,
th
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
>> I'm not sure where we go from here. Your GSOC student has disappeared,
>> right? Is anyone else willing to take up the patch and work on it?
>
> No, he has not disappeared at all. He is going to work on fixing issues
> and getting
Am Mittwoch, 7. Mai 2008 schrieb Tom Lane:
> >> 1.1 Add a column named 'attrel' in pg_attribute catalog to store
> >> column privileges. Now all column privileges are stored, no matter
> >> whether they could be implied from table-level privilege.
>
> What this actually means, but doesn't say, is t
Hello
I am sending little bit smarter version - without redundant parsing.
When test expression is defined, then expressions in WHEN part are
modified like
$x in ( origin_expression )
$x is referenced to invisible *case* variable that carries result of
test expression.
Regards
Pavel Stehule
2
29 matches
Mail list logo
