Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres IDE in VS Code

techcommunity.microsoft.com

Post reply on HN
Print view View original

381–390 of 433 posts

Re: Postgres IDE in VS Code

#381

Post by asrael_io »

diggan wrote: post #365
WuxiFingerHold wrote: post #326

>> all without ever leaving your favorite code editor How do I install this on Neovim then? Is there a LSP? Or is this Microsoft proprietary? I wonder how much better without Copilot integration this is then the competition. I'm using DBeaver CE currently. Does all I need (also for SQLite).

When for-profit companies write "Democratizes X for all" it means "for people who can pay and aren't embargoed". When they write "Simplify" it means "Get locked in to our ecosystem". When they write "Your favorite X" it means "The product we're selling to you", and so on. Once you start reading press releases with this business-dictionary, it gets a lot easier to just close the tab and move on.

i feel like we need a first-era unsuck it search engine for this :D

Re: Postgres IDE in VS Code

#382

Post by overtomanu »

jtougas wrote: post #366

I used Azure Data Studio with SQL Server for a while—decent, but still clunky. I believe this plugin is the evolution of that, so it’s probably solid too—but can't beat out what I'm currently using since it targets only Postgres. It’s going to be tough to beat SQLTools for Sublime Text ( https://code.mteixeira.dev/SublimeText-SQLTools/ ). It’s simple, fast, does the basics right, and crucially, works for many of the…

There is also an extension for VS Code from the same author

https://github.com/mtxr/vscode-sqltools

Re: Postgres IDE in VS Code

#383

Post by Sammi »

wg0 wrote: post #121
pier25 wrote: post #8

Oh woah this looks great. Quite amazing they put the effort into this for Postgres instead of SQL Server. The demand must be a lot higher.

I wish there was something similar for SQLite.

There are several sqlite vs code extensions and this one's my favorite: https://marketplace.visualstudio.com/items?itemName=yy0931.v...

Re: Postgres IDE in VS Code

#384

Post by Sammi »

pbw wrote: post #240

Is there a similar feature available for SQLite? Will there need to be a totally new extension for every DB, or is there a shared portion?

There are multiple vs code extension for sqlite. I tried a few of them and they were not great. Except this one, which I now use daily: https://marketplace.visualstudio.com/items?itemName=yy0931.v...

Re: Postgres IDE in VS Code

#385

Post by codeulike »

petepete wrote: post #342
tomnipotent wrote: post #289

Earlier quoted context omitted.

Those features/tools are still part of SSMS today.

Yeah, it's specifically the old applications I miss. They were really well designed, incredibly snappy and responsive. When SSMS was launched it was really slow and clunky on my computer. I switched to Postgres around that time so I'm 20 years out of touch at this point.

I had forgotten about query analyzer, didn't it exist alongside ssms? I think I used to roll it out when things got really serious

Re: Postgres IDE in VS Code

#386

Post by tough »

xyzzy123 wrote: post #300
semiquaver wrote: post #278

Earlier quoted context omitted.

I’m confused. Isn’t including the canonical state of the database schema in version control along with all the migrations that brought it to that point a completely standard part of every web framework?

It often is, but the schema might be written against a language-specific ORM. That code might in turn have plugins or feature flags that mean you don't know the concrete sql schema until runtime. Same for seed data and migrations. So it depends on the use-case how useful this format is for tooling and discovery vs an actual connection to the database.

Sane ORMs will still use sql for migration files

Re: Postgres IDE in VS Code

#387

Post by OJFord »

tough wrote: post #386
xyzzy123 wrote: post #300

Earlier quoted context omitted.

It often is, but the schema might be written against a language-specific ORM. That code might in turn have plugins or feature flags that mean you don't know the concrete sql schema until runtime. Same for seed data and migrations. So it depends on the use-case how useful this format is for tooling and discovery vs an actual connection to the database.

Sane ORMs will still use sql for migration files

I agree it's much better to, but the biggest ones are probably Django & Rails (?), and they don't.

Re: Postgres IDE in VS Code

#388

Post by tough »

OJFord wrote: post #387
tough wrote: post #386

Earlier quoted context omitted.

Sane ORMs will still use sql for migration files

I agree it's much better to, but the biggest ones are probably Django & Rails (?), and they don't.

yeah tbh i was mostly thinking about the newer crop of ts/js ones (kysely/drizzle) vs the earlier mess that TypeORM or others where on its place, so at least its not so bad.

Re: Postgres IDE in VS Code

#389

Post by Ericson2314 »

cerved wrote: post #292
Ericson2314 wrote: post #184

Microsoft Access meets PostgreSQL, 3 decades later?

Is there something related to Access in this that I missed in this or you just being salty, because I have to work with that garbage and if there's something better than DBeaver I can use for that I'm all ears

I'm just picking Access as an example of an old MS "database GUI".

Re: Postgres IDE in VS Code

#390

Post by cortesoft »

tough wrote: post #386
xyzzy123 wrote: post #300

Earlier quoted context omitted.

It often is, but the schema might be written against a language-specific ORM. That code might in turn have plugins or feature flags that mean you don't know the concrete sql schema until runtime. Same for seed data and migrations. So it depends on the use-case how useful this format is for tooling and discovery vs an actual connection to the database.

Sane ORMs will still use sql for migration files

There are a lot of advantages to using a DSL for migration files rather than pure sql. For one, many times you will get both forward and reverse migration ability automatically, to allow rollbacks (with the ability to mark certain migrations as unable to rollback). You also can have the DSL utilize different features depending on which database you are using without having to change your migration. You can also use special syntax to designate relations between tables easily without having to write the boilerplate SQL every time.

If you are using an ORM, using the same language and mental model to describe your database structure as you do to interact with the database makes a lot of sense.

Post reply on HN