Skip site navigation (1) Skip section navigation (2)

Re: IN/OUT parameters

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: IN/OUT parameters
Date: 2005-05-25 12:04:01
Message-ID: 429469B1.1090003@fastcrypt.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
I think this is the driver's problem. It appears that we are following 
the spec, so lets leave this alone.

Regarding what an OUT parameter might mean. We already have some 
facility in the FE/BE to indicate the types of the returning columns. 
Directionality is implied by where in the bind message these parameters 
are sent. I can see the extra overhead of putting directionality in for 
each column.
I'd agree that changing the FE/BE at this point is not a good idea. 
However, if we ever do get real stored procs, this may be an issue.

I've looked at the driver some more and it appears we parse the sql more 
than once due to the fact that we are supporting v2, and v3 backend 
protocols. At this point I've got to consider the TODO on the jdbc list 
of putting a proper parser in. Are there any javacc wizards around ?

Dave
Tom Lane wrote:

>Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>  
>
>>At this point I'd just like the backend to ignore the OUT parameter if 
>>it were set that way, but allow it to be sent.
>>    
>>
>
>I think you're thinking at the wrong level.  AIUI the issue occurs at
>the Parse stage, long before any parameter value is sent (or not sent).
>
>What you really want, if I'm understanding correctly, is to be able to
>send SQL that looks like this:
>
>	SELECT * FROM myfunc($1,$2,$3);
>
>and then have some of the Param symbols be simply ignored while looking
>up myfunc().
>
>This is pretty ugly in itself, and I'd not want to add a protocol change
>into the mix to make it happen.  But possibly we could do it without any
>protocol-level change.  What would you say to specifying that Params
>that are declared as type VOID are ignored in a function lookup?  What
>this would mean is that you'd need to do the following:
>
>1. The SQL string can look as above.
>
>2. When sending the Parse message, you'd specify the parameter types
>   as, say, INT4/VOID/VOID (or possibly UNKNOWN/VOID/VOID).
>
>3. When sending Bind, you'd have to specify dummy values (probably
>   nulls) for the VOID parameter positions.
>
>While I haven't looked at the backend code yet, I think we could drop
>VOID-type parameters out of the argument list of a function during
>parse analysis without too much trouble.  This would affect *all*
>function calls, not only those appearing in SELECT * FROM, but
>I don't see any legitimate use of VOID-type values that this would
>interfere with.
>
>Klugy, isn't it?  Anyone have a better idea?  Or should we just tell
>Dave that the JDBC driver ought to handle it?
>
>			regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>
>  
>

-- 
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-05-25 13:37:05
Subject: Re: PseudoPartitioning and agregates
Previous:From: Greg StarkDate: 2005-05-25 06:53:03
Subject: Re: PseudoPartitioning and agregates

pgsql-jdbc by date

Next:From: Sergey A. SokolovDate: 2005-05-25 13:36:14
Subject: BIGINT <-> java.lang.String auto cast
Previous:From: Markus SchaberDate: 2005-05-25 11:25:52
Subject: Re: ASCII to UNICODE conversion problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group