Issue 183: Propagate subselect errors properly.

[marshall-mcmullen]

This addresses #183 by propagating subselect errors into newly returned SelectDataset so caller doesn't have to explicitly check for errors in subselects. Let me know what you think @doug-martin.

[marshall-mcmullen]

So I still think there's an issue here that needs work. Specifically, if you use Where using a subselect, we have the exact same problem. Because Where simply copies the where clauses without looking at any errors that might be in the contained subselects. Thoughts @doug-martin ?

[marshall-mcmullen]

Here's an example of what is still not covered by this PR:

func TestSelectWithSubSelectError2(t *testing.T) {

    ds := goqu.From("test").As("t").SetError(fmt.Errorf("An error"))
    assert.NotNil(t, ds.Error())

    ds2 := goqu.Select(Star()).From("table").Where(Ex{"s.id": Select(Star()).From(ds)})
    assert.NotNil(t, ds2.Error())
}

In this case I don't get an error b/c the Where handling doesn't propagate errors. So It expands it to an empty string, yielding a super unhelpful error message from Postgres such as:

pq: SELECT * with no tables specified is not valid"

[doug-martin]

@marshallmcmullen thanks for the PR. Ill get this in the next release and look into the other error cases.

[doug-martin]

@marshallmcmullen I think we can get around this error by having AppendSQL method set the error on the builder, that way when you build the SQL if any nested Dataset will return the first error encountered.

Will that address your use case? Ill open a PR showing what I am thinking.

[marshall-mcmullen]

@marshallmcmullen I think we can get around this error by having AppendSQL method set the error on the builder, that way when you build the SQL if any nested Dataset will return the first error encountered.

Will that address your use case? Ill open a PR showing what I am thinking.

@doug-martin that sounds perfect to me. I didn't realize we could just use AppendSQL to solve this. I think that sounds like a perfect solution.