How to call a remote procedure (stored procedure) about pq

Here's an excessively verbose example since I don't know what error you are getting or where you are stuck (please be more specific):

package main

import (
    _ "github.com/bmizerany/pq"
    "database/sql"
    "fmt"
)

func main() {

    db, err := sql.Open("postgres",
         "user=XXX dbname=XXX host=XXX")
    if err != nil {
        panic(err)
    }

    fetch, err := db.Query(`select url_decode($1::text)`,`%66%6F%6F`)
    if err != nil {
        panic(err)
    }

    var s string
    for fetch.Next() {
        err = fetch.Scan(&s)
        if err != nil {
            panic(err)
        }
        fmt.Println(s)
    }
}

url_decode is this: http://postgres.cz/wiki/PostgreSQL_SQL_Tricks#Function_for_decoding_of_url_code

[the42]

On 12/17/2012 07:17 PM, myannikos wrote:

Here's an excessively verbose example since I don't know what error you
are getting or where you are stuck (please be more specific):

Frankly I didn't tried before but I did not find any example on using
stored procedures with Golang sql/pq so I asked before. So calling a SP
is more or less the same as 1. binding the parameters 2. executing 3.
fetching the returns as with any "regular" select / update / insert?

slightly OT but anyway ... back in the days our DB admins advised us to
use SPs even for "simple" things because of their performance gain
(pre-parsed syntax, execution plan, ...). Is this still true?

package main

import (
_ "github.com/bmizerany/pq"
"database/sql"
"fmt"
)

func main() {

 db,  err  :=  sql.Open("postgres",
      "user=XXX dbname=XXX host=XXX")
 if  err  !=  nil  {
     panic(err)
 }

 fetch,  err  :=  db.Query(`select url_decode($1::text)`,`%66%6F%6F`)
 if  err  !=  nil  {
     panic(err)
 }

 var  s  string
 for  fetch.Next()  {
     err  =  fetch.Scan(&s)
     if  err  !=  nil  {
         panic(err)
     }
     fmt.Println(s)
 }

}

url_decode is this:
http://postgres.cz/wiki/PostgreSQL_SQL_Tricks#Function_for_decoding_of_url_code

—
Reply to this email directly or view it on GitHub
https://github.com/bmizerany/pq/issues/62#issuecomment-11453085.

[fdr]

@the42 the bug reporting form is not a QnA service, ref #61 also. It is a database of misbehavior.

Most postgres drivers are completely unaware of stored procedures: by and large, they only care about query text, return types, and parameters. So, there is no reason they should't work.

Any performance advantages of LANGUAGE SQL (which is importantly not the same as LANGUAGE plpgsql) stored procedures can be captured with prepared statements. There can benefits in avoiding network round trips for procedural code though. One may also find their logs easier to read this way, by ascribing symbolic names to queries.

There are some software engineering advantages to LANGUAGE SQL functions (use by different applications, reading logs, use from an interactive tool like psql, dependency tracking and static analysis at creation time), but there are some cost (having to name things, synchronizing the state between code and the operators installed, versioning) also. What choice of trade-offs works best for your project is up to you, but both are workable and used often.

[the42]

On 28.12.2012 01:38, Daniel Farina wrote:

@the42 https://github.com/the42 the bug reporting form is not a QnA
service, ref #61 https://github.com/bmizerany/pq/issues/61 also. It
is a database of misbehavior.

I am really sorry for this abuse I did after misreading
https://github.com/bmizerany/pq/issues/21#issuecomment-5941855

Most postgres drivers are completely unaware of stored procedures: by
and large, they only care about query text, return types, and
parameters. So, there is no reason they should work.

Last thing: Reading in context I guess you meant "So, there is no reason
they should NOT work."
Thank you for in detail replies. @daniel & @blake

Any performance advantages of |LANGUAGE SQL| (which is importantly not
the same as |LANGUAGE plpgsql|) stored procedures can be captured with
prepared statements. There can benefits in avoiding network round
trips for procedural code though. One may also find their logs easier
to read this way, by ascribing symbolic names to queries.

There are some software engineering advantages to |LANGUAGE SQL|
functions (use by different applications, reading logs, use from an
interactive tool like |psql|, dependency tracking and static analysis
at creation time), but there are some cost (having to name things,
synchronizing the state between code and the operators installed,
versioning) also. What choice of trade-offs works best for your
project is up to you, but both are workable and used often.

—
Reply to this email directly or view it on GitHub
https://github.com/bmizerany/pq/issues/62#issuecomment-11722393.

[fdr]

Last thing: Reading in context I guess you meant "So, there is no reason
they should NOT work."

Yeah, sorry about the error.

Don't sweat using the bug reports to get help; it mostly signifies there's not much other way to do it. I suppose I only wish you had tried it and reported a detailed issue (which, in my thinking, you wouldn't have had), first.

I will probably open a mailing list for this kind of correspondence.

[fdr]

I've also edited the above text (shouldn't vs should) to be more clear for the archives.

This work for me, Greetings

fmt.Print("inserting Persona => ")
sqlStatement := "select * from crear_persona('" + persona.Ci + "','" + persona.Nombre + "','" + persona.App + "','" + persona.Apm + "','" + persona.Cuenta + "','" + persona.Contrasenia + "','" + persona.Estado + "')"
_, err := db.Exec(sqlStatement)
if err != nil {
fmt.Println("Error inserting Persona")
fmt.Println(err)
panic(err)
}
fmt.Println("Persona inserted")

[snorkypie]

@victorhugoviiii I sure do hope that was a joke! (A bad joke at that!)