Personally I suspect this is an uncommon case. Would be nice to see some real world examples.

For example pulling data from https://dev.socrata.com containing goverment data from many countries into a local mysql database to run stats. Example https://data.ct.gov/resource/hma6-9xbg.json?category=Fruit&item=Peaches for that to be successful you need json tags.

Databases in go use the db tag in mysql or datastore in https://cloud.google.com/appengine/docs/go/datastore/reference?hl=en , I think it make sense to use the same struct. So you end up with two tags json and db. The logic approach would be giving it the same value.

https://opendata.rdw.nl/Voertuigen/Open-Data-RDW-Gekentekende_voertuigen_brandstof/8ys7-d773

// Brandstof  SQL
type Brandstof struct {
    BrandstofOmschrijving          string `db:"brandstof_omschrijving" json:"brandstof_omschrijving"`
    BrandstofVolgnummer            string `db:"brandstof_volgnummer" json:"brandstof_volgnummer" sql:"int"`
    BrandstofverbruikBuiten        string `db:"brandstofverbruik_buiten" json:"brandstofverbruik_buiten" sql:"float"`
    BrandstofverbruikGecombineerd  string `db:"brandstofverbruik_gecombineerd" json:"brandstofverbruik_gecombineerd" sql:"float"`
    BrandstofverbruikStad          string `db:"brandstofverbruik_stad" json:"brandstofverbruik_stad" sql:"float"`
    Co2UitstootGecombineerd        string `db:"co2_uitstoot_gecombineerd" json:"co2_uitstoot_gecombineerd" sql:"int"`
    Co2UitstootGewogen             string `db:"co2_uitstoot_gewogen" json:"co2_uitstoot_gewogen" sql:"int"`
    EmissiecodeOmschrijving        string `db:"emissiecode_omschrijving" json:"emissiecode_omschrijving"`
    GeluidsniveauRijdend           string `db:"geluidsniveau_rijdend" json:"geluidsniveau_rijdend" sql:"int"`
    GeluidsniveauStationair        string `db:"geluidsniveau_stationair" json:"geluidsniveau_stationair" sql:"int"`
    Kenteken                       string `db:"kenteken" json:"kenteken"`
    MilieuklasseEgGoedkeuringLicht string `db:"milieuklasse_eg_goedkeuring_licht" json:"milieuklasse_eg_goedkeuring_licht"`
    MilieuklasseEgGoedkeuringZwaar string `db:"milieuklasse_eg_goedkeuring_zwaar" json:"milieuklasse_eg_goedkeuring_zwaar"`
    Nettomaximumvermogen           string `db:"nettomaximumvermogen" json:"nettomaximumvermogen" sql:"float"`
    NominaalContinuMaximumvermogen string `db:"nominaal_continu_maximumvermogen" json:"nominaal_continu_maximumvermogen" sql:"float"`
    Roetuitstoot                   string `db:"roetuitstoot" json:"roetuitstoot" sql:"float"`
    ToerentalGeluidsniveau         string `db:"toerental_geluidsniveau" json:"toerental_geluidsniveau" sql:"int"`
    UitstootDeeltjesLicht          string `db:"uitstoot_deeltjes_licht" json:"uitstoot_deeltjes_licht" sql:"float"`
    UitstootDeeltjesZwaar          string `db:"uitstoot_deeltjes_zwaar" json:"uitstoot_deeltjes_zwaar" sql:"float"`
}

// Insert SQL
func (t Brandstof) Insert(db *sql.DB) error {
...
}

// Truncate SQL
func (t Brandstof) Truncate(db *sql.DB) error {
...
}

Basicly any webapp that uses json in combination with a database that uses db tags as far as I know.

Is there a way I can query for the db, datastore tag on all github go code? As a counter argument suppose if it's not common which I doubt because of how many times I do it in my wepapp projects :) How many lines of code do you expect it takes for this change in golang?

The reason it's not reported before I think is that nobody had to write a big enough struct so they got bored with copy and pasting or they are just very good add vim stuff :)

I would counter-argue that similar packages supporting a common tag name, such as json/xml/gob additionally supporting an 'enc' tag (similar to how they commonly understand TextMarshaler and BinaryMarshaler in addition to their own specific interfaces). A common vocabulary of attributes for this tag could be recognized by each of these packages, and attributes defined in a json/xml/etc tag would take precedence.

One thing that json and xml do not agree on are naming conventions -- if you used a single string to define tag/field names for both, then one or the other would perhaps be unconventional.

The standard library can be made consistent I agree, but database vendors are just going to pull their own tags I'm afraid. I don't think I can convince google cloud to use enc instead of datastore

We could probably make a more informed decision about this issue if the "well known struct tags" wiki page were fleshed out a bit. @gertcuykens would you mind adding the details about the db tag to that page?

Ok I will try to expand this list, when completed I will update the wiki, but what bothers me alot is that packages don't mention there tag system in godoc, and you have to dig in their own documentation to find out what tag names they are using example:

https://godoc.org/github.com/jinzhu/gorm
http://jinzhu.me/gorm/models.html#model-definition

You can already draw a semi conclusion though, and that is everybody want to prevent naming collisions. So you definitely want something to combine them if both need the same string value. Consider it as a toy for your child :P yes you don't going to play with it yourself but some Gophers are going to be very happy with it when they need it. So the question will boil down to how much compiler time and resources is this going to cost :)

@gertcuykens it'd be great if you could update the wiki page with those details. Thank you!

We would need to see compelling evidence that this is a common problem in order to introduce a special case for this. (Suggestions in comments above.)

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please reopen if this is a mistake or you have the requested information.)

Here's one example: https://godoc.org/gopkg.in/juju/charm.v6-unstable#ApplicationSpec

The json, yaml and bson packages all support a very similar (but not identical) subset of struct tag syntax. To make a struct marshal similarly in all of them, you need to duplicate the tags for each kind.

I think it's arguable both ways - by explicitly including the tag, you're essentially declaring that marshaling with that codec is supported, but the duplication can be a pain.

+1 for this, my apps have structs like this one:

type User struct {
Id bson.ObjectId json:"id,omitempty" bson:"_id,omitempty" redis:"id,omitempty" valid:"-"
}

And it really makes the code cleaner to do something like the author suggested