Re: Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString

Uses a slightly longer method of getting the rawoffset and then adding
the DST offset if any.

Cheers,

Kim

On 17 Jul 2003, Kim Ho wrote:

> Uses a slightly longer method of getting the rawoffset and then adding
> the DST offset if any.
>

This is still not good enough. It must be jdk1.1 method to be in the
jdbc1 directory.

Kris Jurka

Kris Jurka wrote:>
> On 17 Jul 2003, Kim Ho wrote:
>
>
>>Uses a slightly longer method of getting the rawoffset and then adding
>>the DST offset if any.
>>
>
>
> This is still not good enough. It must be jdk1.1 method to be in the
> jdbc1 directory.
>

I think is about time to drop support for both JDBC1 and JDK 1.1

--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

Sorry.

The patch (from before) should work with 1.1 as well. FWIW, I agree with
Fernando.

Cheers,

Kim

On Thu, 2003-07-17 at 13:53, Fernando Nasser wrote:
> Kris Jurka wrote:>
> > On 17 Jul 2003, Kim Ho wrote:
> >
> >
> >>Uses a slightly longer method of getting the rawoffset and then adding
> >>the DST offset if any.
> >>
> >
> >
> > This is still not good enough. It must be jdk1.1 method to be in the
> > jdbc1 directory.
> >
>
>
> I think is about time to drop support for both JDBC1 and JDK 1.1
>
>
>
> --
> Fernando Nasser
> Red Hat - Toronto E-Mail: fnasser(at)redhat(dot)com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario M4P 2C9
>

Hi,
Why is that there is a maximum limit of 32 input parameters to the
Postgresql function?

Whereas to my knowledge stored procedures in Oracle and SQL Server
take unlimited number of input arguments. So this puts extra burden on the
middleware developer to handle this stiuation at the time of migrating
existing databases in SQL Server or Oracle to Postgresql.

Thanks,
Arun Desai.

On Mon, 21 Jul 2003, Arun Desai wrote:

> Hi,
> Why is that there is a maximum limit of 32 input parameters to the
> Postgresql function?

The backend's internals are limited in this way. If you compile from
source you can change this limit by altering INDEX_MAX_KEYS. Search the
archives for more details.

Kris Jurka

On Mon, 21 Jul 2003, Arun Desai wrote:

> Kris,
> Would it have any implication on the database in terms of
> performance etc.,. if I change INDEX_MAX_KEYS to a number greater than 32,
> compile the sources and run the database?
>

Yes, otherwise it would be set to a higher value. That said the
performance decrease shouldn't be that bad. The following tests were made
during the change from 16 to 32 and are supposed to demonstrate the worst
case scenario, fast functions being invoked many times. I couldn't say
what the real world impact to you is.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=11&thl=1190037072,1190014321,1189977929,1189879040,1189866197,1189843487,1189825930,1189700130,1189693906,1189683897,1189678002,1189640255&seekm=20020802140556.Q8966%40mail.libertyrms.com#link16

Kris Jurka

Kris,
Would it have any implication on the database in terms of
performance etc.,. if I change INDEX_MAX_KEYS to a number greater than 32,
compile the sources and run the database?

Thanks,
Arun Desai.

----- Original Message -----
From: "Kris Jurka" <books(at)ejurka(dot)com>
To: "Arun Desai" <Arundesai(at)kinera(dot)com>
Cc: "pgsql-jdbc-list" <pgsql-jdbc(at)postgresql(dot)org>
Sent: Monday, July 21, 2003 3:53 PM
Subject: Re: [JDBC] Number of function parameter

>
>
> On Mon, 21 Jul 2003, Arun Desai wrote:
>
> > Hi,
> > Why is that there is a maximum limit of 32 input parameters to the
> > Postgresql function?
>
> The backend's internals are limited in this way. If you compile from
> source you can change this limit by altering INDEX_MAX_KEYS. Search the
> archives for more details.
>
> Kris Jurka
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

On Mon, 21 Jul 2003, Arun Desai wrote:

> Hi,
> Why is that there is a maximum limit of 32 input parameters to the
> Postgresql function?
>
>
> Whereas to my knowledge stored procedures in Oracle and SQL Server
> take unlimited number of input arguments. So this puts extra burden on the
> middleware developer to handle this stiuation at the time of migrating
> existing databases in SQL Server or Oracle to Postgresql.

Just remember, TANSTAAFL (There ain't no such thing as a free lunch)

in some way, you're paying for a limited or unlimited number of args, be
it money, performance, flexibility. for postgresql, the payment is that
it gets pretty good performance on <=32 args, without a bunch of ugly code
to handle "unlimited" args. note that there's still a limit, even in
Oracle, it's likely a performance enforced limit though, i.e. after 1024
args the functions get so slow as to be unusable.

Patch applied.

--Barry

Kim Ho wrote:
> Uses a slightly longer method of getting the rawoffset and then adding
> the DST offset if any.
>
> Cheers,
>
> Kim
>
>
>
>
> ------------------------------------------------------------------------
>
> ? temp.diff
> Index: Makefile
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v
> retrieving revision 1.38
> diff -c -p -r1.38 Makefile
> *** Makefile 12 Feb 2003 06:13:04 -0000 1.38
> --- Makefile 17 Jul 2003 14:23:09 -0000
> ***************
> *** 4,10 ****
> #
> # Copyright (c) 2001, PostgreSQL Global Development Group
> #
> ! # $Header: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v 1.38 2003/02/12 06:13:04 barry Exp $
> #
> #-------------------------------------------------------------------------
>
> --- 4,10 ----
> #
> # Copyright (c) 2001, PostgreSQL Global Development Group
> #
> ! # $Header: /cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v 1.38 2003/02/12 06:13:04 barry Exp $
> #
> #-------------------------------------------------------------------------
>
> Index: org/postgresql/jdbc1/AbstractJdbc1Statement.java
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java,v
> retrieving revision 1.27
> diff -c -p -r1.27 AbstractJdbc1Statement.java
> *** org/postgresql/jdbc1/AbstractJdbc1Statement.java 9 Jul 2003 05:12:04 -0000 1.27
> --- org/postgresql/jdbc1/AbstractJdbc1Statement.java 17 Jul 2003 14:23:11 -0000
> *************** public abstract class AbstractJdbc1State
> *** 2072,2078 ****
> if (timezoneLocation>7 && timezoneLocation+3 == s.length())
> {
> timezone = Integer.parseInt(s.substring(timezoneLocation+1,s.length()));
> ! localoffset = java.util.Calendar.getInstance().getTimeZone().getOffset(millis);
> if (s.charAt(timezoneLocation)=='+')
> timezone*=-1;
> }
> --- 2072,2081 ----
> if (timezoneLocation>7 && timezoneLocation+3 == s.length())
> {
> timezone = Integer.parseInt(s.substring(timezoneLocation+1,s.length()));
> ! // localoffset = java.util.Calendar.getInstance().getTimeZone().getOffset(millis);
> ! localoffset = java.util.Calendar.getInstance().getTimeZone().getRawOffset();
> ! if (java.util.Calendar.getInstance().getTimeZone().inDaylightTime(new java.sql.Date(millis)))
> ! localoffset += 60*60*1000;
> if (s.charAt(timezoneLocation)=='+')
> timezone*=-1;
> }
> *************** public abstract class AbstractJdbc1State
> *** 2101,2107 ****
> if (timezoneLocation != -1 && timezoneLocation+3 == s.length())
> {
> timezone = Integer.parseInt(s.substring(timezoneLocation+1,s.length()));
> ! localoffset = java.util.Calendar.getInstance().getTimeZone().getOffset(millis);
> if (s.charAt(timezoneLocation)=='+')
> timezone*=-1;
> }
> --- 2104,2113 ----
> if (timezoneLocation != -1 && timezoneLocation+3 == s.length())
> {
> timezone = Integer.parseInt(s.substring(timezoneLocation+1,s.length()));
> ! // localoffset = java.util.Calendar.getInstance().getTimeZone().getOffset(millis);
> ! localoffset = java.util.Calendar.getInstance().getTimeZone().getRawOffset();
> ! if (java.util.Calendar.getInstance().getTimeZone().inDaylightTime(new java.sql.Time(millis)))
> ! localoffset += 60*60*1000;
> if (s.charAt(timezoneLocation)=='+')
> timezone*=-1;
> }
> *************** public abstract class AbstractJdbc1State
> *** 2146,2152 ****
> if (timezoneLocation>8 && timezoneLocation+3 == s.length())
> {
> timezone = Integer.parseInt(s.substring(timezoneLocation+1,s.length()));
> ! localoffset = java.util.Calendar.getInstance().getTimeZone().getOffset(millis);
> if (s.charAt(timezoneLocation)=='+')
> timezone*=-1;
> }
> --- 2152,2161 ----
> if (timezoneLocation>8 && timezoneLocation+3 == s.length())
> {
> timezone = Integer.parseInt(s.substring(timezoneLocation+1,s.length()));
> ! // localoffset = java.util.Calendar.getInstance().getTimeZone().getOffset(millis);
> ! localoffset = java.util.Calendar.getInstance().getTimeZone().getRawOffset();
> ! if (java.util.Calendar.getInstance().getTimeZone().inDaylightTime(new java.sql.Timestamp(millis)))
> ! localoffset += 60*60*1000;
> if (s.charAt(timezoneLocation)=='+')
> timezone*=-1;
> }
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

Unsubscribe

Send an email to majorodomo(at)postgresql(dot)org containing the following line
in the body:

unsubscribe pgsql-jdbc

This email must be sent from the email address which is currently
subscribed to the list which may not be your current email address
if you have any forwarding/redirecting going on.

Kris Jurka

On Thu, 31 Jul 2003, Arun Desai wrote:

> Unsubscribe
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>