-
Notifications
You must be signed in to change notification settings - Fork 1k
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
[YSQL] "alter procedure" causes spurious warning #2717
Comments
Hi! I was able to compile oracle comparability functions for postgres (orafce - https://github.com/orafce/orafce) using postgres extension library - just a "make" with gcc, g++, bin including pg_config and LD_LIBRARY_PATH including postgres/lib.
Thanks |
Summary: `ALTER FUNCTION` can be used to change the definition of a function. This diff supports `ALTER FUNCTION` in YSQL. Test Plan: Unit Test ybd --java-test org.yb.pgsql.TestPgRegressPgMiscIndependent Reviewers: tnayak, dmitry, mihnea Reviewed By: mihnea Subscribers: tramer, karthik, kannan, yql Differential Revision: https://phabricator.dev.yugabyte.com/D10777
@bllewell -- ALTER FUNCTION works. There is still support needed for alter procedure/routine/aggregate. |
Summary: `ALTER FUNCTION` can be used to change the definition of a function. This diff supports `ALTER FUNCTION` in YSQL. Test Plan: Unit Test ybd --java-test org.yb.pgsql.TestPgRegressPgMiscIndependent Reviewers: tnayak, dmitry, mihnea Reviewed By: mihnea Subscribers: tramer, karthik, kannan, yql Differential Revision: https://phabricator.dev.yugabyte.com/D10777
This has been open for over two years. I re-tested in YB-2.11.1.0. An alter procedure attempt still causes the same "0A000: ALTER PROCEDURE not supported yet" with the same reference to this issue. Notice that create or replace (or drop and then create) is a viable workaround for alter. But this does require that you have the source definition to hand. If you drop it, you also have to re-grant any privileges that have been granted on it. |
Summary alter function works now (in YB-2.13.0.1) —and you don't get any warnings. alter procedure also works but draws warnings. @m-iancu, @ramsrivatsa: Pls. change the code to remove these spurious warnings. (But see Issue #11523.) Detail Try the testcase below first in vanilla PG and then in YB. Make sure to change the name of the spool file to reflect the environment so that you can use your favorite diff program to compare the two files. I used PG Version 14.1 and YB-2.13.0.1. The script exercises every single variant of alter procedure according to the account in the PostgreSQL doc, with the exception of alter procedure depends on extension. Notice that both of "alter function/procedure depends on extension" work bu case a spurius error. Issue #11523 tracks this. (Notice that Issue #11495 points out that neither alter procedure nor alter function is yet documented in the YSQL doc.) In YB, every other alter procedure execution draws a warning except for this one, which completes silently:
This one:
draws this warning:
And every other alter procedure variant draws this warning:
In PG (of course) the script finishes silently. But the two spool files are identical. Note: warnings go to stdout and not to the spool file. This allows the the spooled output to be identical in YB and PG despite the warnings that are drawn in YB. TESTCASE
Here is the spooled output:
See the attached issue-2717.zip. It contains demo.sql, pg-spool.txt, and yb-spool.txt. Execute demo.sql first in PG (completes silently) and then in YB (causes spurious warnings). Make sure to set the |
Jira Link: DB-1669
I need to use this syntax:
In a multi-user, multi-schema application design in pursuit of good security. I want to lock down name resolution to prevent subversion of my design intention by nefariously created synonyms and the like.
Attempting this in YB Version 2.0.1 causes this error:
Notice that Issue #1155 is closed, and is too generic for the present use case. See my new issue #2718 asking that the HINT text be updated to point to this issue (#2717).
See Issue #17315. This shows that if you restart the YB cluster with this YSQL configuration parameter setting:
then every 0A000 error becomes a warning and that, not withstanding what the message says, metadata queries show that the alter statement (in at least some variants) has its intended effect. Specific tests for this variant (not shown here) show that it, too, does, then, indeed have its intended effect.
The text was updated successfully, but these errors were encountered: