Обсуждение: AM/PM times? Am I going crazy?

Hi -
    It appears that postgres considers 1pm to really be 1am???  The
following is occuring on 7.0.2.  Am I missing something obvious?


devloki=>  select CURRENT_TIMESTAMP;
       timestamp
------------------------
 2000-08-08 11:23:29-07
(1 row)

devloki=> select TO_CHAR(timestamp '2000-08-08 13:00:00-07', 'am');
 to_char
---------
 am
(1 row)

devloki=> select TO_CHAR(timestamp '2000-08-08 14:00:00-07', 'am');
 to_char
---------
 pm
(1 row)

On Tue, 8 Aug 2000, Philip Hallstrom wrote:

> Hi -
>     It appears that postgres considers 1pm to really be 1am???  The
> following is occuring on 7.0.2.  Am I missing something obvious?


The PM/AM bug is already fixed in the current CVS tree.


                                        Karel

Karel Zak <zakkr@zf.jcu.cz> writes:

> On Tue, 8 Aug 2000, Philip Hallstrom wrote:
>
> > Hi -
> >     It appears that postgres considers 1pm to really be 1am???  The
> > following is occuring on 7.0.2.  Am I missing something obvious?
>
>
> The PM/AM bug is already fixed in the current CVS tree.

Any chance of getting a patch towards 7.0.2 or a 7.0.3? TIA.

--
Trond Eivind Glomsrød
Red Hat, Inc.

On 8 Aug 2000, Trond Eivind[iso-8859-1]  Glomsrřd wrote:

> Karel Zak <zakkr@zf.jcu.cz> writes:
>
> > On Tue, 8 Aug 2000, Philip Hallstrom wrote:
> >
> > > Hi -
> > >     It appears that postgres considers 1pm to really be 1am???  The
> > > following is occuring on 7.0.2.  Am I missing something obvious?
> >
> >
> > The PM/AM bug is already fixed in the current CVS tree.
>
> Any chance of getting a patch towards 7.0.2 or a 7.0.3? TIA.

 Not sure. In current CVS is changed 'fmgr' matter for all
build-in functions, this not allow easy prepare a patch :-((

 You can try use CVS sources.

                        Karel

Karel Zak <zakkr@zf.jcu.cz> writes:

> On 8 Aug 2000, Trond Eivind[iso-8859-1]  Glomsrřd wrote:
>
> > Karel Zak <zakkr@zf.jcu.cz> writes:
> >
> > > On Tue, 8 Aug 2000, Philip Hallstrom wrote:
> > >
> > > > Hi -
> > > >     It appears that postgres considers 1pm to really be 1am???  The
> > > > following is occuring on 7.0.2.  Am I missing something obvious?
> > >
> > >
> > > The PM/AM bug is already fixed in the current CVS tree.
> >
> > Any chance of getting a patch towards 7.0.2 or a 7.0.3? TIA.
>
>  Not sure. In current CVS is changed 'fmgr' matter for all
> build-in functions, this not allow easy prepare a patch :-((
>
>  You can try use CVS sources.

I can't use a CVS snapshot for our release...


--
Trond Eivind Glomsrød
Red Hat, Inc.

Hi -
    I have a table that has a varchar field (fname).  I'd like to
create an index on UPPER(fname), but am running into problems...

What I don't understand is that I can do "SELECT UPPER(fname) FROM
mytable" and it works just fine.  I also tried creating a SQL function
that did upper for me, but then the create index complains I can't use SQL
functions this way.

Hmm... I just tried creating a plpgsql function and now I can create the
index just fine...

Is this the only way to do it?  How come there's no
UPPER(varchar) function?

Just curious...

Thanks!

-philip

devloki=> create index foo on rolo_entry (UPPER(fname));
ERROR:  DefineIndex: function 'upper(varchar)' does not exist
devloki=> create index foo on rolo_entry (UPPER(varchar(fname)));
ERROR:  parser: parse error at or near "varchar"
devloki=> create index foo on rolo_entry (UPPER(text(fname)));
ERROR:  parser: parse error at or near "("
devloki=> create index foo on rolo_entry (UPPER(text fname));
ERROR:  parser: parse error at or near "fname"
devloki=> create index foo on rolo_entry (UPPER(fname::text));
ERROR:  parser: parse error at or near "::"
devloki=> create index foo on rolo_entry (UPPER(CAST(fname AS TEXT)));
ERROR:  parser: parse error at or near "cast"

devloki=>
devloki=> create function varcharupper(varchar) returns text as '
devloki'> begin
devloki'> return upper($1);
devloki'> end;
devloki'> ' LANGUAGE 'plpgsql';
CREATE
devloki=> select varcharupper('test');
 varcharupper
--------------
 TEST
(1 row)

devloki=> create index foo on rolo_entry (varcharupper(fname));
CREATE
devloki=>

Hi -
    The following statements lock up my machine completely (I can
ping, but can't telnet, nothing).  This is FreeBSD 3.4-STABLE running
7.0.2.

rolo_entry.fname is of type VARCHAR(30).



devloki=> CREATE FUNCTION upper(VARCHAR) RETURNS TEXT AS '
devloki'>   BEGIN
devloki'>   RETURN UPPER($1);
devloki'>   END;
devloki'> ' LANGUAGE 'plpgsql';
CREATE
devloki=> CREATE INDEX foo_idx ON rolo_entry (upper(fname));


If I rename the function to say "am_upper" it works just fine.

???

Philip Hallstrom <philip@adhesivemedia.com> writes:

> Hi -
>     The following statements lock up my machine completely (I can
> ping, but can't telnet, nothing).  This is FreeBSD 3.4-STABLE running
> 7.0.2.
>
> rolo_entry.fname is of type VARCHAR(30).
>
> devloki=> CREATE FUNCTION upper(VARCHAR) RETURNS TEXT AS '
> devloki'>   BEGIN
> devloki'>   RETURN UPPER($1);
> devloki'>   END;
> devloki'> ' LANGUAGE 'plpgsql';
> CREATE
> devloki=> CREATE INDEX foo_idx ON rolo_entry (upper(fname));
>
> If I rename the function to say "am_upper" it works just fine.
>
> ???

I'm guessing that since sql is case insensitive, that results in
infinite recursion because you have a function upper() which calls
UPPER().

--
Prasanth Kumar
kumar1@home.com