Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?)
Date
Msg-id 22070.1096741370@sss.pgh.pa.us
Whole thread Raw
In response to Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?)
Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> What I'm inclined to do with these is change pg_proc.h but not force
>> an initdb.  Does anyone want to argue for an initdb to force it to be
>> fixed in 8.0?  We've lived with the wrong labelings for some time now
>> without noticing, so it doesn't seem like a serious enough bug to
>> force a post-beta initdb ... to me anyway.

> I'd prefer if all users of 8.0 were guaranteed to have the same catalog.  

Well, there's something to be said for that viewpoint too.  Anyone else
feel the same?

If we do go for an initdb, I'd like at the same time to do something
I had intended to do but forgotten, which is to yank the functions
and operators for basic arithmetic on type "char", and instead put in
(explicit) conversions between "char" and integer.  See for instance
http://archives.postgresql.org/pgsql-sql/2002-11/msg00116.php
http://archives.postgresql.org/pgsql-general/2004-08/msg01562.php
http://archives.postgresql.org/pgsql-general/2004-09/msg01209.php

Specifically I want to remove these operators:
oid |        oid        | oprresult 
-----+-------------------+-----------635 | +("char","char")  | "char"636 | -("char","char")  | "char"637 |
*("char","char") | "char"638 | /("char","char")  | "char"
 

and their underlying functions:
oid  |           oid            | prorettype |   prosrc    
------+--------------------------+------------+-------------1248 | charpl("char","char")    | "char"     | charpl1250 |
charmi("char","char")   | "char"     | charmi  77 | charmul("char","char")   | "char"     | charmul  78 |
chardiv("char","char")  | "char"     | chardiv
 

The following operators on "char" will remain:
oid |        oid        | oprresult 
-----+-------------------+----------- 92 | =("char","char")  | boolean630 | <>("char","char") | boolean631 |
<("char","char") | boolean632 | <=("char","char") | boolean633 | >("char","char")  | boolean634 | >=("char","char") |
boolean

These are not as dangerous as the arithmetic operators, because in a
situation where the parser is having difficulty resolving types, it
will prefer the "text" comparison operators over these.  The reason
the "char" arithmetic operators are dangerous is that they are the only
ones of those names in the STRING type category.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd
Next
From: Gavin Sherry
Date:
Subject: Re: SQL-Invoked Procedures for 8.1