Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I have a little patch that actually allows SPI_prepare() to
> > use UNKNOWN_OID in the passed in parameter type array and
> > put's the choosen datatypes Oid back into there.
>
> > The parser treats those parameters like single quoted
> > literals of unknown type and chooses what would be the most
> > useful datatype here.
>
> > Any objections?
>
> For this particular application, at least, I do not see the value ...
> in fact this seems more likely to break stuff than help. If the
> application does not know what the datatypes are supposed to be,
> how is it going to call the prepared statement?
Right now using UNKNOWN_OID in that place leads to a parse
error, what makes me feel absolutely comfortable that there
will be nobody using it today. So what kind of "break" are
you talking about?
>
> You could possibly get away with that for a textual interface ("always
> pass quoted literals"), but it would surely destroy any chance of having
> a binary protocol for passing parameters to prepared statements.
Right. And BTW, how do you propose that the client
application passes the values in binary form anyway? Are you
going to maintain that process for backwards compatibility
when we change the internal representation of stuff (like we
want to for numeric) or who? And what about byte ordering?
User defined types?
I think the backend is the only one who can convert into it's
personal, binary format. Wouldn't anything else lead to
security holes?
>
> Offhand I'm having a hard time visualizing why you'd want this at
> the SPI_prepare level, either ... what's the application?
It propagates up to the SPI level. In fact it is down in the
parser/analyzer.
There are DB interfaces that allow a generic application to
get a description of the result set (column names, types)
even before telling the data types of all parameters.
Our ODBC driver for example has it's own more or less
complete SQL parser to deal with that case! I don't see THAT
implementation very superior compared to the ability to ask
the DB server for a guess. I thought that this PREPARE
statement will be used by such interfaces in the future, no?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
