radusuciu / django-sqlfun Goto Github PK

In my attempts to dogfood this package I've encountered issues with the SqlFunDefinition table not existing and specifically, I'm seeing that error when first calling makemigrations. This makes sense because I'm overriding makemigrations so I think we've got a chicken and egg sort of situation.

The implementation of get_function_name stands in the way of this.

CREATE OR REPLACE doesn't work if we change the number of arguments for instance. For this project, I want to be able to do that and right now I don't want to support different functions with the same name since that requires keeping track of the arguments. A more complete solution might also leverage ALTER FUNCTION when possible, but I'm opting for simplicity of design here.

Relevant from the postgres docs:

CREATE FUNCTION defines a new function. CREATE OR REPLACE FUNCTION will either create a new function, or replace an existing definition. To be able to define a function, the user must have the USAGE privilege on the language.

If a schema name is included, then the function is created in the specified schema. Otherwise it is created in the current schema. The name of the new function must not match any existing function or procedure with the same input argument types in the same schema. However, functions and procedures of different argument types can share a name (this is called overloading).

To replace the current definition of an existing function, use CREATE OR REPLACE FUNCTION. It is not possible to change the name or argument types of a function this way (if you tried, you would actually be creating a new, distinct function). Also, CREATE OR REPLACE FUNCTION will not let you change the return type of an existing function. To do that, you must drop and recreate the function. (When using OUT parameters, that means you cannot change the types of any OUT parameters except by dropping the function.)

When CREATE OR REPLACE FUNCTION is used to replace an existing function, the ownership and permissions of the function do not change. All other function properties are assigned the values specified or implied in the command. You must own the function to replace it (this includes being a member of the owning role).

If you drop and then recreate a function, the new function is not the same entity as the old; you will have to drop existing rules, views, triggers, etc. that refer to the old function. Use CREATE OR REPLACE FUNCTION to change a function definition without breaking objects that refer to the function. Also, ALTER FUNCTION can be used to change most of the auxiliary properties of an existing function.

The user that creates the function becomes the owner of the function.

Currently the app_label is being kept with SqlFunDefinition, and this might get out of sync if a function is moved from one app to another. This may not matter - in which case, maybe we can drop this field from SqlFunDefinition.

The cache is keyed by pdm.lock + python_version, but we're adding Django and that's leading to this:

Post job cleanup.
/usr/bin/tar --posix -cf cache.tgz --exclude cache.tgz -P -C /home/runner/work/django-sqlfun/django-sqlfun --files-from manifest.txt -z
Failed to save: Unable to reserve cache with key setup-pdm-Linux-python-3.10.10-4f0814a0c8159b25eabf4fb37207c145316d58c9ccc20fd43817ae5e358aaad9, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/main, Key: setup-pdm-Linux-python-3.10.10-4f0814a0c8159b25eabf4fb37207c145316d58c9ccc20fd43817ae5e358aaad9, Version: 01890d4adc3ae75cb75b320168589250487b820dcbcdb518d1908d87a447a692

Currently this means that if we delete a migration file, then a new one will not be generated unless we also delete the entry in the SqlFunDefinition table. There needs to be a flag that is toggled depending on whether or not the migration has been run, or we need to avoid adding these instances until migrate.

This also needs some tests.