On 25/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Anton Melser" <[EMAIL PROTECTED]> writes:
>
> >> You'd have to do something like
> >> DELETE FROM pg_operator WHERE oprcode = 'anytextcat'::regproc;
> >> since there isn't any higher-level command that will let you delete a
> >> built-in oper
"Anton Melser" <[EMAIL PROTECTED]> writes:
>> You'd have to do something like
>> DELETE FROM pg_operator WHERE oprcode = 'anytextcat'::regproc;
>> since there isn't any higher-level command that will let you delete a
>> built-in operator.
>>
>> I recommend practicing on a scratch database ;-)
> T
> You'd have to do something like
> DELETE FROM pg_operator WHERE oprcode = 'anytextcat'::regproc;
> since there isn't any higher-level command that will let you delete a
> built-in operator.
>
> I recommend practicing on a scratch database ;-)
Thanks for the tip, though alas that didn'
"Anton Melser" <[EMAIL PROTECTED]> writes:
>> Too many. You might have to remove the anynonarray || text and
>> text || anynonarray operators if you're going to continue to rely
>> on implicit casts to text.
> Thanks for that. Any chance someone could give me more newbie instructions?
You'd have
> > Anyway, maybe I spoke too soon :-(.
>
> > ERROR: operator is not unique: integer || unknown
>
> > I did, of course, not follow the instructions and just blinding
> > applied them all, but from reading them it doesn't look like the issue
> > here. Does this error mean there are too many oper
"Anton Melser" <[EMAIL PROTECTED]> writes:
> Anyway, maybe I spoke too soon :-(.
> ERROR: operator is not unique: integer || unknown
> I did, of course, not follow the instructions and just blinding
> applied them all, but from reading them it doesn't look like the issue
> here. Does this error m
> > I have the suspicion that his mother is named Lois, his father is
> > unknown and he has a sensitivity to Kryptonite. But that's just
> > speculation of course...
> >
> > Alban Hertroys
>
>
> Superman married Lois, I hope that isn't his Mom's name.
I got that he was the *son* of Superman.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 18:13:27 +0100
Alban Hertroys <[EMAIL PROTECTED]> wrote:
> On Mar 21, 2008, at 5:58 PM, Anton Melser wrote:
>
> > Tom the Champion strikes again!
> > Cheers
> > Anton
>
> I have the suspicion that his mother is named Lois, his fa
On Mar 21, 2008, at 5:58 PM, Anton Melser wrote:
Tom the Champion strikes again!
Cheers
Anton
I have the suspicion that his mother is named Lois, his father is
unknown and he has a sensitivity to Kryptonite. But that's just
speculation of course...
Alban Hertroys
--
If you can't see the
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Anton Melser" <[EMAIL PROTECTED]> writes:
> > ... But it is COMPLETELY out of the
>
> > question to redo the db abstraction layer, and without these implicit
> > casts that is what will be needed. Is there REALLY no way to reenable
> > it?
>
"Anton Melser" <[EMAIL PROTECTED]> writes:
> ... But it is COMPLETELY out of the
> question to redo the db abstraction layer, and without these implicit
> casts that is what will be needed. Is there REALLY no way to reenable
> it?
http://people.planetpostgresql.org/peter/index.php?/archives/18-Rea
> > - Is there a way to turn it back to the old behaviour with a
> >warning going to the logs?
>
>
> No.
>
>
> > - Is there a way to get v8.2.x to warn on the dubious casts
> >so we can tighten the application side while on v8.2?
>
>
> Seems to me the easiest way would be to try it ou
On Wed, Nov 14, 2007 at 06:56:06PM +1300, Martin Langhoff wrote:
> Hmmm. We'll have to test and see if we have any in Moodle.
All that has happened is that the *implicit* casting is gone. They will
now simply produce errors, the fix being to explicity cast it to the
type you wanted, rather than th
Tom Lane wrote:
> Martin Langhoff <[EMAIL PROTECTED]> writes:
>> I say they are worrying because Moodle code has many ocurrences of
>>/* bla.id is an INT8 */
>>SELECT x,y,z FROM bla WHERE id='1';
>> And we also often quote INT values for inserts/updates, I am not sure if
>> this is supporte
Martin Langhoff <[EMAIL PROTECTED]> writes:
> I say they are worrying because Moodle code has many ocurrences of
>/* bla.id is an INT8 */
>SELECT x,y,z FROM bla WHERE id='1';
> And we also often quote INT values for inserts/updates, I am not sure if
> this is supported either.
This is not
Hi all -
I've spotted the cast-related "regressions" being discussed here
http://archives.postgresql.org/pgsql-general/2007-11/msg00505.php
... as a Moodle developer supporting Pg, the stricter cast rules in pg
8.3 are somewhat worrying. Is there a straightforward way to configure a
given DB or a
16 matches
Mail list logo
