> > > So actually an equality test against INT_MAX would be correct. But making
> > > that clear in the comment would probably not be a bad idea :-)
> >
> > I have applied a fix for this, because it obviously needed fixing
> > regardless of if it fixes the original issue all the way. Still looking
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > So actually an equality test against INT_MAX would be correct. But making
> > that clear in the comment would probably not be a bad idea :-)
>
> I have applied a fix for this, because it obviously needed fixing
> regardless of if it fixes the origin
On Sun, 2007-06-05 at 21:30 -0400, Tom Lane wrote:
> You can do it always if you simply decrement the weight for each leading
> zero removed.
On reflection, the patch as given was wrong anyway: if two Numerics are
identical except for the presence of leading zeroes, we can't consider
the weight wh
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2007-03-05 at 23:57 -0400, Tom Lane wrote:
>> Hm, but apply hash_any() to the remaining digits? That might work, if
>> you are careful about how you factor the weight into it (or just not try
>> to use the weight in the hash).
> Attached is a patc
On Thu, 2007-03-05 at 23:57 -0400, Tom Lane wrote:
> Hm, but apply hash_any() to the remaining digits? That might work, if
> you are careful about how you factor the weight into it (or just not try
> to use the weight in the hash).
Attached is a patch that implements this idea. Since leading or t
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sun, 2007-06-05 at 00:20 -0400, Andrew Dunstan wrote:
>> I object to the short notice. I think we need to give people a chance to
>> adjust their configs
> Sure, I can wait a few days (although if we're going to do this for 8.3,
> we should do it promp
On Sun, May 06, 2007 at 01:33:47PM -0400, Andrew Dunstan wrote:
> However, there are still some oddities. For example, a change to or
> removal of the base type affects the array type, but the array type
> can be directly operated on (e.g. alter type _aa set schema foo ).
> I'm inclined to say we
I wrote:
OK, summarising what looks to me like a consensus position, ISTM the
plan could be:
. fix makeArrayTypeName() or similar to make it try harder to generate
a unique non-clashing name
. remove the existing "62 instead of 63" name length restrictions
. autogenerate array types for a
Andrew Dunstan wrote:
> I think we need to give people a chance to
> adjust their configs, especially on the buildfarm, where those who
> have currently simply removed the --enable-integer-datetimes setting
> will need to adjust their configs.
Why? They have previously been testing the default an
Neil Conway wrote:
On reflection, it might actually be wiser to
delay making this change until the beginning of the 8.4 cycle...
I think that's probably true, but I can live with it either way as long
as there's enough notice.
cheers
andrew
---(end of broadca
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Pa
Hello
This patch contains implementation of table functions defined in ANSI
SQL 2003 (Conformance with SQL2003: T326 Table functions). Patch adds
new proargmode PROARGMODE_TABLE (based on PROARGMODE_OUT). Columns of
output table are similar OUT arguments, but don't generate any
variables.
Propos
Peter Eisentraut wrote:
Andrew Dunstan wrote:
I think we need to give people a chance to
adjust their configs, especially on the buildfarm, where those who
have currently simply removed the --enable-integer-datetimes setting
will need to adjust their configs.
Why? They have previous
13 matches
Mail list logo
