Assuming that you are dealing with geographic coordinates and geographic (true north) bearings, you have a couple of options:
Project the situation onto the plane, solve using the simple planar coordinates method, and reverse project back to the spheroid.
Perform geodetic or spherical geometry calculations.
If your distances are not too great and your accuracy requirements are not too tight, the first is probably the easier solution.
Broken down, this amounts to
a. Project the two geographic points to plane grid points via a suitable map projection. Ideally, this would be Gnomonic projection because it projects great circles as straight lines. (For a treatise on that, see Algorithms for geodesics by CFF Karney, aka @cffk.) However, a UTM projection method is probably the more common and suitable alternative available. Yet another compromise, suggested by @whuber in a comment to calculating-the-distance-between-a-point-and-a-virtual-line-of-two-lat-lngs, is to treat the geographic coordinates as though they were planar, pre-multiply the difference in longitudes (between A and B) by the cosine of their average latitudes.
b. Convert the geographic azimuths to grid bearings via the meridian convergence. In theory, I believe all well-defined projections have computable grid convergences, as well as scale factors. (See calculate grid convergence: True North to Grid North for an example for the UTM case.)
c. Calculate the point of intersection via the planar method. (See my other answer here for this same question.)
d. Reverse project the intersection point back from grid to geographic coordinates. (Projections, in either direction, are the subject of too many questions on GIS SE to mention here.)
I believe you can achieve this effect in PostGIS via the ST_Project() and ST_Intersection() functions:
geogC ← ST_Intersection (ST_Project (geogA, bigdist, azimA), ST_Project (geogB, bigdist, azimB))
where
geogA and azimA are geographic point A and azimuth at A, respectively,
geogB and azimB are geographic point B and azimuth at B, respectively, and
bigdist is an arbitrary but appropriately large enough distance to ensure an intersection.
I conclude that such use of the ST_Project() and ST_Intersection() is equivalent to the algorithm I describe because of the note in the user manual for ST_Intersection():
For geography this is really a thin wrapper around the geometry implementation. It first determines the best SRID that fits the bounding box of the 2 geography objects (if geography objects are within one half zone UTM but not same UTM will pick one of those) (favoring UTM or Lambert Azimuthal Equal Area (LAEA) north/south pole, and falling back on mercator in worst case scenario) and then intersection in that best fit planar spatial ref and retransforms back to WGS84 geography.
As for the second, more rigorous solution, I do not know of even a spherical trigonometry solution, let alone an ellipsoidal trigonometry one. I suspect the solution is very difficult to explain here in simple terms.