You can’t do that since they are not Postgres commands, strictly not “common” [to all databases]!
Those commands are implemented by psql, which is just another client (a REPL, of sorts), and it does it by translating into a proper SQL query.
A workaround is: select * from table_name limit 0;
which may give you the info you need (see link above for other ways, giving more complete info). That is standard SQL (“limit” wasn’t for a while, I believe is by now, so this trick should work on all databases up to recent standards).
A shorter version:
TABLE table_name limit 0;
TABLE is a synonym in PostgreSQL for “select * from” and needs not be upper case. I think it’s not standardized (I believe it’s taken from MySQL), so I would advice to not use in in production code, if you ever want to move to another (only) standard conforming database.
No, didn’t work in mine, and likely never will. You likely have MySQL in mind. These things are different between databases. And why I say “never” because, it means something different in PostgreSQL (I’m not sure also an extension there or my SQL standard, never used this):
That seems like an (intentional) feature of DataFrame
s package. So it it configurable I would look there. Note, it wouldn’t just “cut off” data, just for display purposes.
I wouldn’t know about docs of ODBC.jl (or LibPQ.jl), but LibPQ library is probably the fastest for Postgres; all (likely) use it directly or indirectly, so if you are e.g. using ODBC you would have a small overhead. The point of ODBC is to be able to switch to another database without changing your code, so it provides some abstraction. If you are just learning, I wouldn’t worry too much, and even some (time-series) databases provide the PostgreSQL API, so LibPQ.jl would still work, but that’s the exception.
What would be possible is to provide an SQL/PostgreSQL REPL mode, and if you’re lucky you would nerd-snipe someone to do it. If it’s an interesting problem enough… I’m not sure it is, but yes, would be useful (I doubt it should be part of LibPQ, because it could/should? work across databases, but LibPQ or that REPL mode could implement \d).
That’s a problem with open source (not always). Docs are best written by new users, you can help, make a PR, as they know the problems that need describing (writing docs does not qualify as nerd-sniping? so devs might overlook to do or improve them). Users like me, very familiar with Postgres, might not need any or much help. I at least used LibPQ without any problems. In that particular case, the docs might be minimal, because such users would know to look at the upstream docs, and many might rather use the alternatives, e.g. ODBC.