Postgres IDE in VS Code • Hacker News Board

Re: Postgres IDE in VS Code

#331

Post by what » Sat, May 24, 2025, 4:56 AM UTC

seveibar wrote: post #163

netghost wrote: post #107

Earlier quoted context omitted.

That seems like a really pragmatic tool, thanks for sharing it! I'm curious, do you output triggers, store procedures, and such? Many tools seem to stop after you've defined tables, columns, and indices, but I'd love some better tooling to make use of the rest of the DB's features.

Yep! It basically runs pg_dump and categorizes all of the output into different files so it should be comprehensive. I think there's `functions/function_name.sql`, `misc.sql`, `triggers.sql` etc.

You built it but you don’t know what it outputs?

Re: Postgres IDE in VS Code

#332

Post by infamia » Sat, May 24, 2025, 5:02 AM UTC

tomnipotent wrote: post #319

infamia wrote: post #311

Earlier quoted context omitted.

VSCode's marketing was that it is an open source editor you could rely upon, complete with open source extensions for popular languages like Python. Then when once it became popular and vscodium was growing in popularity (a vscode fork), MS locked things down. Now the Python extensions are closed source, and MS has artificially prevented vscode forks from using those extensions. A bait and switch if I've ever seen on…

> VSCode's marketing Point to this marketing. Here's the blog announcement on the 1.0 releases - what I can't find are any examples of Microsoft over-promising. https://web.archive.org/web/20160422123116/https://code.visu... > MS locked things down... and MS has artificially prevented vscode forks from using those extensions Or like any growing and maturing project they established boundaries - one of which was that…

> Their existing and continued contributions to vscode are significant, so I think they can be allowed to keep some cards up their sleeves like the plugin marketplace or their Python extension.

It would have been fine if MS had started with their Python extension being proprietary, that would have been up front and transparent. Instead, they lured folks in (no small part due to open source), and once it became popular, they started turning the screws and making things proprietary and locking it down.

> I'm just flabbergasted at this idea that somehow we're entitled to everything vscode-adjacent "just because"

You're not arguing in good faith at this point. I don't think it is unreasonable to ask someone to make their intentions known up front do you? Instead MS waited until vscode became popular (partly because everything was open source) and then altering the deal Vader style closing off parts of vscode and extensions that were open. That doesn't feel particularly transparent.

> or that Microsoft is obligated to subsidize other billion-dollar business by giving them free features for their vscode forks.

I have no idea what you're talking about here. Vscodium is an entirely free and open source fork, no one makes any money from it afaik.

> Where's the bait? Where's the switch? If the best you have is that they released a closed source plugin I'm going to bucket this as another borrowed opinion.

They released the Python stack as fully open source. Then released the proprietary one, deprecating the open source one. Then made double certain that vscodium or any of the other forks could not use it at all, even if the use manually downloaded the extension. How is that not a bait and switch?

Re: Postgres IDE in VS Code

#333

Post by BoorishBears » Sat, May 24, 2025, 5:34 AM UTC

tempaccount420 wrote: post #241

BoorishBears wrote: post #162

Earlier quoted context omitted.

Which is strictly worse than just giving the LLM access to the source of truth for the database. You're adding a round trip to the database and the LLM and inserting a tool call in the conversation before it even starts generating any code. And the reference Postgres MCP implementation doesn't include Postgres types or materialized views, and is one of the most widely used packages: Zed.dev's MCP server for example,…

I don't see how a round trip of If designed well - by suspending generation in memory and inserting a , without restarting generation and fetching cache from disk - the round trip/tool call is better (costs the equivalent of 50 tokens for waiting + function_result tokens).

You're dealing with the full TTFT x2 + the tokens all the prompts of all your MCPs before you even get to that round trip to the DB.

And you don't have to wonder about "if designed well": the reference implementation that's getting 20k downloads a week and getting embedded in downstream editors is is not designed well and will make the round trip every time and still not give the LLM the full information of the table.

Most MCP implementations are crappy half-assed implementations in similar fashion because everyone was rushing to post how they added to MCP.

And if you're worried about "context fatigue" (you mean LLMs getting distracted by relevant information...), you should 100% prefer a well known schema format to N MCP prompt definitions with tool usage instructions that weren't even necessarily tuned for the LLM in question.

LLMs are much more easily derailed by the addition of extra tools and having to reason about when to call them and the results of calling them, than they are a prompt caching friendly block of tokens with easy to follow meaning.

Re: Postgres IDE in VS Code

#334

Post by ajsharp » Sat, May 24, 2025, 5:53 AM UTC

and just like that, 90% of the reason i pay for a jetbrains license just...disappeared

Re: Postgres IDE in VS Code

#335

Post by throwaway2037 » Sat, May 24, 2025, 5:59 AM UTC

ajsharp wrote: post #334

and just like that, 90% of the reason i pay for a jetbrains license just...disappeared

The difference? JetBrains won't pull the rug on you, or abandon the product at the next turn in the road.

Re: Postgres IDE in VS Code

#336

Post by throwaway2037 » Sat, May 24, 2025, 6:01 AM UTC

0cf8612b2e1e wrote: post #39

hobs wrote: post #30

Earlier quoted context omitted.

They built the postgres plugin in a way that nobody could usefully contribute to unless they worked at msft - like the rest of ADS the level of control they tried to maintain meant nobody wanted to work on it.

That is seemingly true of a bunch of tools. I am using an official Microsoft Python library - the repo is public on GitHub, but all of the CI or other backend integration is behind the Microsoft curtain, so it is impossible for the public to actually participate. The cherry on top is that the team that used to support the tool was impacted, so now nobody can maintain the thing.

I am curious: Which library?

Re: Postgres IDE in VS Code

#337

Post by chrisvalleybay » Sat, May 24, 2025, 6:17 AM UTC

codingjerk wrote: post #172

dpflan wrote: post #85

Earlier quoted context omitted.

I wonder about people’s development workflows. If you are using a tool like this, how much time are you spending in the command-line (where all such tools can be interfaced)? Are most tools used wrapped in some layer like this?

I spend most of my time in the command line: - neovim for file editing, - zsh (+zoxide) for navigation / file management, - plain git to manage my repos, - plain text note taking and accounting, etc.

Try lazygit. It is truly amazing.

Re: Postgres IDE in VS Code

#338

Post by jen20 » Sat, May 24, 2025, 7:15 AM UTC

semiquaver wrote: post #278

seveibar wrote: post #77

This solves a major problem that I built an npm package called "pgstrap"[1] for. It generates a "database structure" directory so that my database schema is available to LLMs (it also makes code review easier because you can see the changes to various tables). So I have a SQL file for each table in my database, neatly organized into directories for each schema. Rails has a similar idea with schema.rb I'm not sure whe…

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?

The _canonical_ state is what is in the production database(s). What's in version control is hopefully able to recreate it, with the obvious caveat of being highly unlikely to be able to repopulate the data.

Re: Postgres IDE in VS Code

#339

Post by pjmlp » Sat, May 24, 2025, 7:15 AM UTC

osigurdson wrote: post #113

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.

SQL server is in "cash cow mode" at this point. Investing more into tooling is unlikely to increase revenues at this stage.

I can think of several improvements for Transact-SQL, starting with stored procedure packages.

Re: Postgres IDE in VS Code

#340

Post by pjmlp » Sat, May 24, 2025, 7:17 AM UTC

ahartmetz wrote: post #149

teruakohatu wrote: post #143

Earlier quoted context omitted.

> going all in on open source over the past 10-15 years. Given that there are many Microsoft closed source extensions for VS Code, that cannot legally be used with the open source Version of VS Code, I would say they are not going all in. Knee deep maybe.

Because of the closed extensions situation, the open source part feels insincere. Sort of like a free plan up to 10 users and then pretty expensive situation. The purpose isn't the free plan, it's just an advertising measure to get people to where you really benefit eventually.

As most of the big corps contributing to open source.