Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init_custom.sql #16

Open
nenadnoveljic opened this issue Nov 1, 2019 · 2 comments
Open

init_custom.sql #16

nenadnoveljic opened this issue Nov 1, 2019 · 2 comments

Comments

@nenadnoveljic
Copy link
Contributor

Do you agree to adding the @init_custom call at the end of init.sql (just before termout on)? init_custom.sql itself wouldn't be delivered by you. Customers could rather optionally create it to preserve their own preferences after a new deployment. I intentionally specified the single @ to allow multiple users with different preferences have their own init_custom.sql in their search path.

@tanelpoder
Copy link
Owner

Yes, I've thought about that option in past too. I could put init_custom.sql to .gitignore so people can keep the init_custom.sql within the TPT script if they want (to avoid having multiple paths).

By the way, we could even go the way of calling @init_custom.sql after the typical "COLUMN x y z" formtting clauses in scripts like asqlmon.sql, xb.sql etc... so people who desire to hide some special column (with NOPRINT) or make it wider/narrower, could customize this in their personal init_custom.sql too. This is why I have deliberately prefixed output column names with the script names in many of my scripts. On the other hand, this would add a dependency into those scripts (the @init_custom.sql must exist, otherwise it will throw an error). Would make using some scripts stand-alone a little less nice. So I'd leave this as an idea for now. But yes to init_custom.sql ... so I guess i'd need to create it zero size to avoid init.sql throwing errors and not make any updates to it myself?

@nenadnoveljic
Copy link
Contributor Author

nenadnoveljic commented Nov 4, 2019

Would make using some scripts stand-alone a little less nice.

Unless the termout gets temporarily switched off. Of course, on condition that tolerating the SP2- message in the spool file is a viable option.

so I guess i'd need to create it zero size to avoid init.sql throwing errors and not make any updates to it myself?"

Mind, that unlike PATH, the current directory seems to get prepended to the SQLPATH, so the local empty init_cust would take precedence over a init_cust in SQLPATH if init was called from the scripts directory. An alternative would be not to delivery the empty init_cust, call it anyway, but before termout off - of course, if tolerating the SP2 message in the spool file is acceptable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants