Pass STATE messages to stdout about target-postgres

[airhorns]

@robmoore yep. Thats the intention. It won't however store it or automagically do anything with it, so managing the state and passing the previous state into the next invocation is still the user's responsibility, not target-postgres'.

[airhorns]

Is there any guidance on why this target doesn't support actually doing something with STATE messages? Is it that it's hard, or not needed by the original authors? I would have figured everyone needed to store STATEs somewhere, and I feel like the big database all the data is going into is as good a place as any. @AlexanderMann perhaps you could comment -- do you ever want to support storing state messages somehow in this target?

[AlexanderMann]

Hey @airhorns, sorry, was on vacation then got swamped with a client!

So some easy questions then the meaty one:

Do you ever want to support storing state messages somehow in this target?

Presently, no. I don't see the benefit to this as I think it muddies the presently single concern of a target of "I get information, I persist it" and instead would make it need to somehow understand state which I think is typically only useful for the tap right?

The meaty question:

any guidance on why this target doesn't support actually doing something with STATE messages? Is it that it's hard, or not needed by the original authors?

DataMill originally crafted a runner for Singer taps and targets to handle state and whatnot. This took state out of the input and did some voodoo on it to persist it remotely as you can imagine wanting to persist STATE messages to something like s3, Postgres, etc. which is different than the target.

This is to say, we didn't need it and felt that ignoring it to start was simpler and got something "pretty-good" working much more quickly.

Conclusion

I think your PR of #130 handles this in a more robust way for all folks if I'm not mistaken? I'd propose that being the conclusion to this issue.

If folks have other suggestions, I'm definitely up for hearing it!

(Also thanks everyone in here for contributing, super helpful)

[robmoore]

@airhorns Will the changes in #130 output state for use by the tap on future runs?

[AlexanderMann]

Addressed in v0.1.9