ious what
> that would look like for SQL, or if that is even desirable.
> There is a pre-existing db/sql issue to discuss tracing (which
> would also facilitate metrics collection):
> https://github.com/golang/go/issues/18080
>
>
> On Mon, 10 Sep 2018 at 09:22 Conrad Wood w
On Mon, 2018-09-10 at 09:05 +0100, Tristan Colgate wrote:
> There are two existing projects used to achieve similar goals:
>
> https://github.com/ExpansiveWorlds/instrumentedsql
> https://github.com/gchaincl/sqlhooks
>
> native support could probably improve things a little, but this is a
> very
On Mon, 2018-09-10 at 09:44 +0200, Jan Mercl wrote:
>
> On Mon, Sep 10, 2018 at 8:16 AM Conrad Wood
> wrote:
>
> > Wdyt? Is that a patch that would be acceptable and generally
> useful?
>
> It could be tried and evaluated first as an external package.
>
>
Hi,
I'm thinking of an addition to the sql package. I like to call an
interceptor on each completed statement. I'm interested in timing
information (prometheus in my case) and status codes.
There may be other useful information, such as, number of rows (for
"selects"), which we could make
2017 15:30:12 UTC+1, Domain Admin wrote:
>
>
>
> On 10/18/2017 03:08 AM, Conrad Wood wrote:
> > I did (admittedly found it only after I send the email). I give that a
> > try and see how it goes - thank you!
> >
> > And advice on point #2 by any chance?
> Wh
017 13:42, "Conrad Wood" <c...@conradwood.net> wrote:
> > Hi,
> >
> > We're considering Go for new services in our software architecture.
> > Generally it seems like a good fit. There are a few things I'm not
> > sure about though, so I wonder what others do:
Hi,
We're considering Go for new services in our software architecture.
Generally it seems like a good fit. There are a few things I'm not sure
about though, so I wonder what others do:
1. How does one ensure repeatable builds? (go get obviously pulls from the
internet by default.to get
