Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

database/sql: support output parameters #18079

Closed
kardianos opened this issue Nov 28, 2016 · 5 comments
Closed

database/sql: support output parameters #18079

kardianos opened this issue Nov 28, 2016 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@kardianos
Copy link
Contributor

It may be possible to add support output parameters. Look into the benefit and cost of doing so.

@quentinmit quentinmit added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 29, 2016
@quentinmit quentinmit added this to the Go1.9 milestone Nov 29, 2016
@kardianos
Copy link
Contributor Author

The Oracle driver has support for output parameters but can't expose it in the sql package at this time:
https://github.com/rana/ora

@kardianos kardianos self-assigned this Jan 12, 2017
@gopherbot
Copy link

CL https://golang.org/cl/38533 mentions this issue.

@kardianos
Copy link
Contributor Author

@mattn @jackc @tgulacsi @mjibson @cbandy @julienschmidt @methane

Feedback requested for https://golang.org/cl/38533 . I need assistance in determining the correct API for OUTPUT parameters with regards to INOUT parameters.

Currently I specify an argument is for an OUTPUT parameter by passing a pointer value inside of

// Out may be used to retrieve OUTPUT value parameters from stored procedures.
//
// Drivers that support Out must implement the driver.NamedValueChecker.
//
// Example usage:
//
//   var outArg string
//   _, err := db.ExecContext(ctx, "ProcName", sql.Named("Arg1", Out{Dest: &outArg}))
type Out struct {
	// Dest is a pointer to the value to populate with the result of the
	// stored procedure's OUTPUT parameter.
	Dest interface{}
}

This works because this is part of a larger CL that allows drivers to accept additional parameter types.

Right now for MS SQL Server POC I'm sending the value to the server for both OUTPUT and INOUT situations and setting the fByRefValue flag on it. This works for MS SQL Server.

Do we need to differentiate between OUTPUT and INOUT parameters for Oracle, Posgresql, or MySQL? For instance, should we have an In bool field or something similar? On some drivers, maybe we ignore that field, but others use it to determine if it gets set to the server or not?

@jackc
Copy link

jackc commented May 18, 2017

I don't think it will matter for PostgreSQL. It does not have true stored procedures, it has functions. And the idiomatic way of calling them is with select. Function output params are just a convenient way for returning a row instead of a single value.

So for PG I think it would remain idiomatic to use QueryRow("select myfunc(42)").Scan(...)

@decibel
Copy link

decibel commented May 19, 2017

Technically, for Postgres it would be better to do "SELECT * FROM myfunc(...)". I know there's some changes around calling an SRF in the SELECT clause coming in 10, though I don't recall the details.

@golang golang locked and limited conversation to collaborators May 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants