unsubscribe
Number of function parameter
От:
"Arun Desai" <Arundesai@kinera.com>
Дата:
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.
Re: Number of function parameter
От:
"Arun Desai" <Arundesai@kinera.com>
Дата:
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"
To: "Arun Desai"
Cc: "pgsql-jdbc-list"
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
Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString
От:
Kim Ho <kho@redhat.com>
Дата:
Uses a slightly longer method of getting the rawoffset and then adding the DST offset if any. Cheers, Kim
Re: Fix for using JDK1.2 instead of JDK1.4 method in
От:
Kim Ho <kho@redhat.com>
Дата:
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@redhat.com > 2323 Yonge Street, Suite #300 > Toronto, Ontario M4P 2C9 >
Re: Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString
От:
Fernando Nasser <fnasser@redhat.com>
Дата:
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@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9
Re: Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString
От:
Barry Lind <blind@xythos.com>
Дата:
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@postgresql.org
Re: Fix for using JDK1.2 instead of JDK1.4 method in
От:
Kris Jurka <books@ejurka.com>
Дата:
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
Re: Number of function parameter
От:
Kris Jurka <books@ejurka.com>
Дата:
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
Re: Number of function parameter
От:
Kris Jurka <books@ejurka.com>
Дата:
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
Re: Number of function parameter
От:
"scott.marlowe" <scott.marlowe@ihs.com>
Дата:
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.
Re: unsubscribe
От:
Kris Jurka <books@ejurka.com>
Дата:
Send an email to majorodomo@postgresql.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@postgresql.org so that your > message can get through to the mailing list cleanly >
