pgrx icon indicating copy to clipboard operation
pgrx copied to clipboard

Adding a flag that forces `CREATE OR REPLACE FUNCTION` statements

Open sumerman opened this issue 3 years ago • 3 comments
trafficstars

Adding a flag that forces CREATE OR REPLACE FUNCTION statements instead of plain CREATE FUNCTION statements pgx now produces by default.

The new default (#554) is potentially less destructive to pre-existing objects and more secure. Unfortunately, it complicates the upgrade path when using versioned shared objects.

sumerman avatar Jun 01 '22 11:06 sumerman

LGTM. Much appreciated

Thank you! Could you approve the workflow to run?

sumerman avatar Jun 01 '22 14:06 sumerman

Thank you! Could you approve the workflow to run?

Done.

eeeebbbbrrrr avatar Jun 01 '22 14:06 eeeebbbbrrrr

A CLI flag that alters this behavior is a uniform hammer and does not account for other use cases which may want a composition of the two. ( Though this might still be what is desired if all you want is a hammer for now. )

workingjubilee avatar Jun 01 '22 16:06 workingjubilee

I have opened #683 which serves as an alternative solution to this problem.

workingjubilee avatar Sep 13 '22 01:09 workingjubilee

I have opened #683 which serves as an alternative solution to this problem.

Thank you for addressing this! #683 is ever so slightly more work for us, but we'll be fine 😄

sumerman avatar Sep 13 '22 15:09 sumerman

Closing in favor of #683

sumerman avatar Sep 13 '22 15:09 sumerman

I don't want to create more work for you, truly! We just are inevitably going to get "so, how about something that lets me have one function CREATEd and one function REPLACEd?" and then we'll have wanted #683 all along.

workingjubilee avatar Sep 13 '22 19:09 workingjubilee

I don't want to create more work for you, truly! We just are inevitably going to get "so, how about something that lets me have one function CREATEd and one function REPLACEd?" and then we'll have wanted #683 all along.

No worries! As I’ve said — we’ll be fine 😅 I completely agree that #683 is more flexible and covers more use cases.

sumerman avatar Sep 14 '22 07:09 sumerman