On Friday, November 8, 2019 at 10:27:32 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Nov 8, 2019 at 11:40 AM André Eriksson > wrote:
> >
> > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
> >>
> >> On Fri, Nov 8, 20
On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson > wrote:
> >
> > Interesting. Do you have a reference to where that happens?
>
> The method (*Package).rewriteCall in cmd/cgo/gcc.go
or wrote:
>
> On Fri, Nov 8, 2019 at 9:08 AM André Eriksson > wrote:
> >
> > That works in simple cases, but does not work when the expression is an
> untyped constant, like 1 or nil. In the case of 1 the variable will get a
> concrete type of int, while fn may accept a
at 5:51:10 PM UTC+1, Michael Jones wrote:
>
> If expr was evaluable in the original code then why not rewrite in place
> after assigning temporaries?
>
> go fn(e1,e2)
>
> {
> t1,t2 := e1,e2
> go func() {
> defer instrument()
> fn(t1,t2)
> }
>
>
>
I am working on a type of Go preprocessor that rewrites source code to add
additional instrumentation to certain types of statements.
One such statement is the go statement. I would like to instrument the
newly created goroutine, injecting some instrumentation code at the start
and finish of
Daniel,
I agree that multiple queries are commonplace. I was referring to multiple
transactions within a single request to be rare, and when it happens you
don't necessarily want to share the same (read-only, isolation level)
properties.
You do have a point that there is a use case for making
Daniel, I would characterize the use case you describe as a very indirect
way of setting these options on transactions. That's can be a good thing
when contexts are already passed around, and coming up with new ways of
passing such options down through a few layers of code is some amount of
