Opened 8 years ago
Last modified 4 years ago
#3692 new task
Write up developer docs on how to format code so doesn't get mangled by our parsers — at Version 1
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | Website Management, Bots |
Component: | documentation | Version: | master |
Keywords: | Cc: |
Description (last modified by )
There are a lot of gotchas with our perl scripts as I am discovering trying to get the BRIN logic to be conditionally installed based on if they are not present.
AS noted by strk, these aren't explained anywhere.
Things like
1) DO commands have to use $$ (can't use a named delimiter) or our parser does crazy things with it when making upgrade
2) Conveniently whatever is created in a DO is picked up by the uninstall (which won't be used by DROP EXTENSION anyway, but important for old-fashioned folks and our current regress), as long as set CREATE statements are not indented.
3) Purpose of postgis_drop_before.sql and postgis_drop_after.sql for use to prevent ambiguous this and that when converting a function that has no default args to have default args, or when renaming function args.
4) Purpose of putting Availability and Changed notes in script files and how the perl upgrade script generator uses that information.