fix: use sqlalchemy_url property in get_uri for postgresql provider

[rawwar]

closes: #38187
related : #38195

Update get_uri to return URI in sqlAlchemy URI format.

[rawwar]

@Taragolis , based on your comment here

As far as i remember, we recently discuss this case in slack. I guess better introduce sa_uri property (or some similar naming) which returns sqlalchemy.engine.URL into the DbApiHook without any implementation, e.g. raise NotImplementedError and implements it per hook which have implementation for SQAlchemy.

I guess we leave the implementation of get_uri dependent on the provider type. If so, do we really need to have sa_uri property with NotImplementedError? Since SqlAlchemy URI is pre-defined, we can consider using the connection and try to form the URI. Raise an error if it has issues. What do you think?

EDIT: I updated the PR according to your original comments.

[Taragolis]

DBApiHook.get_uri has ambiguous and not well documented usage, so there is consideration that it might be any of the usage of this property, depends on implementations. There is 24 Hooks (±couple) right now so it turned into the hell all implementations of DBApiHook which I guess should be more or less interface/protocol implementation rather than actual implementation, except generic things, if it even possible

The problem right now that every single change in DBApiHook spread across many of the implementations and we do not have any tools and methods to control that.

I would rather do not mix-in introduce changes into DBApiHook and other hook in the same PR unless absolutely necessary. So I would rather create a new propery (via separate PR), describe where it could be used right now and where it could be used in the future.

After start implements into the other hooks with potential usage in particular this hook. And after it implements in many (more that 50% I guess) community supported hooks we might start use it internally in DBApiHook, e.g. obtain SA Connections, pandas dataframes and others, with backward compatible logic to the previous implementation for prevent case if hook do not implements this one and for some unknown reason it work (or not) previously. So we could reduce number of potential mistakes which spread across other hooks.

If we talk about this PR, it is not clear what at this moment it fix, new property it is fine, but there is no any description about this property and how to use it.

[rawwar]

I would rather do not mix-in introduce changes into DBApiHook and other hook in the same PR unless absolutely necessary. So I would rather create a new propery (via separate PR), describe where it could be used right now and where it could be used in the future.

I understand. I will first make the updates to the DBApiHook and then go ahead with the individual provider updates.

If we talk about this PR, it is not clear what at this moment it fix, new property it is fine, but there is no any description about this property and how to use it.

I understand. Thanks for the feedback. What I intended to do is as you described here . To have a property sa_uri in the DBApiHook which doesn't have any implementation. But, rather a placeholder property that should be implemented in the providers that use SqlAlchemy URI. This property returns the sqlalchemy.engine.URL object which can be used by the get_uri to form a SqlAlchemy-based URI. Hope I am making sense.

For now, I will separate out the PR.

[rawwar]

@Taragolis , all tests passed. can this be merged?