[{"_1":2,"_161":-5,"_162":-5},"loaderData",{"_3":4,"_17":18,"_25":26,"_140":141},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","routes/_layout",{"_19":-5,"_20":21,"_22":21,"_23":11,"_24":21},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_27":28,"_29":-5,"_30":11,"_31":11,"_32":33,"_34":35,"_36":-5,"_37":11,"_38":39,"_88":-5,"_89":90,"_129":-5,"_130":11,"_131":21,"_132":11,"_133":-5,"_134":11,"_135":-5,"_136":137,"_138":91,"_139":-7},"canonicalUrl","https://hub.docker.com/r/stepankuzmin/pgrebase/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","stepankuzmin","reponame","pgrebase","cloudBuildSource","isAutobuildsAvailable","repo",{"_40":41,"_42":43,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":55,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":62,"_64":65,"_66":-5,"_67":68,"_69":70,"_71":11,"_72":33,"_73":74,"_79":21,"_80":81,"_85":33,"_86":87},"categories",[],"content_types",[44],"image","date_registered","2018-07-04T09:57:02.61103Z","description","PgRebase allows you to easily handle your postgres codebase for functions, triggers and views.","is_private","last_updated","2018-08-01T10:52:41.093897Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[56],"application/vnd.docker.container.image.v1+json","name","pull_count",480,"repository_type","star_count",1,"status","status_description","active","source","collaborator_count",0,"full_description","# PgRebase\n\nPgRebase is a tool that allows you to easily handle your postgres codebase for\nfunctions, triggers and views.\n\n\n## Why\n\nIf you started outsourcing data manipulation to your database through\npostgresql cool features, you probably realized this is painful. Postgresql's\nfunctions, triggers and views are not your usual codebase, they\nlive in postgres, and you often have to drop them if you want to edit them, eg\nwhen you change a function signature. You could edit them directly in psql, but\nthen it's migrating servers / other devs installation that becomes difficult.\n\nThe classic tool for this is the migration software, asking you to manage\nmigration files. This is great for handling tables, not so great to make\nfrequent changes to your functions. Can we do better?\n\n> Still confused about what the problem is here? See [this more in depth explanation](https://news.ycombinator.com/item?id=12976026) on Hacker News.\n\n\n## What\n\nPgRebase allows you to manage your functions/triggers/views as plain files in\nfilesystem. You put them in a `sql/` directory, one file per\nfunction/trigger/type/view.\n\n```\n$ tree sql/\nsql/\n├── functions/\n│ └── assign_user_to_team.sql\n├── triggers/\n│ └── user_updated_at.sql\n└── views/\n └── user_json.sql\n```\n\nNo need to add drop statement in those files, PgRebase will take care of it.\n\nIn watch mode (useful for development), just save your file, pgrebase will\nupdate your database. In normal mode (useful for deployment), pgrebase will\nrecreate all functions/triggers/views found in your filesystem directory.\n\nYou can now work with postgres codebase live reload, then call pgrebase just\nafter your migration task in your deployment pipeline.\n\n\n## Install\n\n```\ngo get github.com/oelmekki/pgrebase\n```\n\nBinary will be in `$GO_PATH/bin/pgrebase`. This is a static binary, so it's\nsafe to copy it in your project (providing any system calling it is from the\nsame architecture).\n\nYou can also download prebuilt PgRelease [from release page](https://github.com/oelmekki/pgrebase/releases/)\n(only for linux/amd64).\n\n\n## Usage\n\n```\n$ export DATABASE_URL=postgres://user:pass@host/db\n\n$ ./pgrebase sql/\nLoaded 10 functions\nLoaded 25 views\nLoaded 5 triggers - 1 trigger with error\n error while loading sql/triggers/user_updated_at.sql\n column users.updated_at does not exist\n\n\n$ ./pgrebase -w sql/\nLoaded 10 functions\nLoaded 25 views\nLoaded 6 triggers\nWatching filesystem for changes...\nFS changed. Building.\n```\n\nWhen working in development environment, you'll probably want to use watch mode\n(`-w`) to have your changes automatically loaded.\n\nFor deployment, add `pgrebase` to your repos and call it after your usual\nmigrations step:\n\n```\nDATABASE_URL=your_config ./pgrebase ./sql\n```\n\nPgRebase can also be used as a library rather than a command tool. See the `core`\nsubpackage.\n\n## Handling dependencies\n\nYou can specify dependencies for files using require statement, provided those\nfiles are of the same kind. That is, function files can specify dependencies on\nother function files, type files can define dependencies on other type files,\netc.\n\nHere is an example about how to do it. Let's say your `sql/functions/foo.sql`\nfiles depends on `sql/functions/whatever/bar.sql`:\n\n```\n$ cat sql/functions/foo.sql\n-- require \"whatever/bar.sql\"\nCREATE FUNCTION foo()\n[...]\n```\n\nFilenames are always relative to your target directory (`sql/` in that\nexample), and within in, to the code kind (`functions/` here).\n\nDo not try to do funky things like adding `./` or `../`, this is no path\nresolution, it just tries to match filenames.\n\nYou can add multiple require lines:\n\n```\n-- require \"common.sql\"\n-- require \"hello/world.sql\"\n-- require \"whatever/bar.sql\"\nCREATE FUNCTION foo()\n[...]\n```\n\nThere is no advanced debugging for circular dependencies for now, so be sure\nnot to get too wild, here (or else, you will have a \"maybe there's circular\ndependencies?\" message and you will have to figure it out for yourself).\n\n\n## Caveats\n\n* pgrebase doesn't keep any state about your codebase and does not delete what\n is in your database and is not in your codebase. This means that if you want\n to remove a trigger/type/view/function, deleting its file is not enough. You\n have to use your usual way to migrate db and remove it.\n\n* trigger files should contain both trigger creation and the function it uses.\n This is to avoid dropping function still used by trigger (if processing\n functions first) or create trigger before its function (if triggers are\n processed first)\n\n* files should only contain the definition of the view/function/type/trigger\n they're named after (with the exception of trigger files declaring the\n function they use). Hazardous results will ensue if it's not the case: only\n the first definition will be dropped, but the whole file will be loaded in\n pg.\n\n* pgrebase single top concern is to not delete any data. This means that no\n DROP will CASCADE. This means that if your database structure depends on\n anything defined in pgrebase codebase, it will fail to reload it when it\n implies dropping it (that is, most of the time). In other terms, do not\n use pgrebase managed functions as default value for your tables' fields.\n\n## Any issue?\n\nPgrebase is a fairly recent project. I already use it on production and it works\nfine for me, but given I'm probably its only user for now, it's probably biased\ntoward how I write my sql code. If you find any problem while parsing your sql\ncode, please [let me know](https://github.com/oelmekki/pgrebase/issues)!\n\n\n## Credits\n\nPgRebase was born after discussing with Derek Sivers about moving business logic\nto the database. Make sure to read [his research](https://sivers.org/pg), it's\nawesome!\n\n## License\n\n

\n \n $\"CC0\"$ \n \n
\n To the extent possible under law,\n \n Olivier El Mekki\n has waived all copyright and related or neighboring rights to\n PgRebase.\n

\n","has_starred","hub_user","immutable_tags_settings",{"_75":11,"_76":77},"enabled","rules",[78],".*","is_automated","permissions",{"_82":21,"_83":11,"_84":11},"read","write","admin","user","storage_size",296972333,"orgData","recentTags",[91],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":65,"_128":21},"content_type","creator",438521,"full_size",4369004,"id",30372105,"images",[101],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":65,"_117":-5},"architecture","amd64","digest","sha256:cf4cbfec4b7a76b07bb99057e30ef7acc8b97aa578407ee0330cebc80984f903","features","","last_pulled","2026-10-05T07:51:54.194836595Z","last_pushed","2018-08-01T10:52:41Z","os","linux","os_features","os_version","size","variant","2018-08-01T10:52:40.356433Z","last_updater","last_updater_username","media_type","latest","repository",5693882,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":142,"_149":150,"_136":159,"_160":11},{"_40":143,"_42":144,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":145,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":62,"_64":65,"_66":-5,"_67":68,"_69":70,"_71":11,"_72":33,"_73":146,"_79":21,"_80":148,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":147},[78],{"_82":21,"_83":11,"_84":11},"tags",{"_151":62,"_152":-5,"_153":-5,"_154":155},"count","next","previous","results",[156],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":157,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":65,"_128":21},[158],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":65,"_117":-5},[],"canDeleteTags","actionData","errors"]

stepankuzmin/pgrebase

Tags for stepankuzmin/pgrebase