Not with ANSI standard SQL it isn't, no. Well, that's not strictly true. You can do left outer joins and put in enough to cover the likely maximum depth but unless you restrain the max depth and include that many joins, it won't always work.
If your set of rows is sufficiently small (say less than 1000), just retrieve them all and then figure it out. It'll be faster than single read traversals in all likelihood.
You could batch the parent traversal. Have a query like:
SELECT t1.id id1, t1.parent parent1,
t2.id id2, t2.parent parent2,
t3.id id3, t3.parent parent3,
t4.id id4, t4.parent parent4,
t5.id id5, t5.parent parent5
FROM mytable t1
LEFT OUTER JOIN mytable t2 ON t1.parent = t2.id
LEFT OUTER JOIN mytable t3 ON t2.parent = t3.id
LEFT OUTER JOIN mytable t4 ON t3.parent = t4.id
LEFT OUTER JOIN mytable t5 ON t4.parent = t5.id
WHERE t1.id = 1234
and extend it to whatever number you want. If the last retrieved parent isn't null you aren't at the top of the tree yet so run the query again. This way you should hopefully reduce it to 1-2 roundtrips.
Other than that you could look at ways of encoding that data in the ID. This isn't recommended but if you limit, say, each node to having 100 children you could say that node with an ID 10030711 has path of 10 -> 03 -> 07 -> 11. That of course has other problems (like max ID length) and of course it's hacky.
It's also worth noting that there are two basic models for hierarchical data in SQL. Adjacency lists and nested sets. Your way (which is pretty common) is an adjacency set. Nested sets wouldn't really help with this situation though and they are complicated to do inserts on.