-
Notifications
You must be signed in to change notification settings - Fork 14
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
Parser issue - DML in WITH query #31
Comments
So the problem seems to be the WITH query: virtual relations generated by UPDATE or DELETE don't seem to work. |
Hey, running into a similar issue. Was wodering when this might be worked on. As it stands, I'm unable to use piggly against my production code. |
Hi @born-in-brooklyn, if you can provide some sample code that doesn't parse, I could take a closer look at this issue. I don't recall implementing the parsing grammar for WITH or CTEs, so adding it might be straightforward. |
sure! here's the function definition:
And here's the error:
Thanks |
I think the error might be related to the presence of a call to raise warning. strictly speaking these are probably not necessary in order to make the application work, but I would rather not remove them |
Hi @born-in-brooklyn, I'm not able to reproduce this. Did you install it from RubyGems or from source? My guess is the last RubyGems release is outdated (and doesn't support GET STACKED DIAGNOSTICS from #28), so you could try installing from source. Let me know if that does or doesn't work! I'll release a new gem once we figure it out. |
Hi @kputnam Thanks for this. It took me a while to get around to it, but I was able to test, and the new code you mentioned above certainly helps with the GET STACKED DIAGNOSTICS issue. I was unable to build from source (having windows/ruby problems, and I'm not a terribly adept ruby dev) so I overlayed the changes in the above mentioned PR in the appropriate ruby lib directory, and it worked. I do however have another problem. there are a number of the procs I have to test that use custom types as input parameters. These Procs fail to be analyzed, throwing the following error:
Does piggly support custom types as input parameters to functions/procs? the type I seem to be having problems with types defined like so:
and is used in a function like this:
please let me know if you need more info. Thanks again for all your help! |
Hi, @born-in-brooklyn, sorry for the delay. It looks like the problem might be that piggly doesn't recognize the argument types are from the I changed def main(argv)
...
elsif config.dry_run?
require 'pp'
pp procedures
puts procedures.map{|p| p.signature }
exit 0
end
... Which printed this when running [#<Piggly::Dumper::ReifiedProcedure:0x00000101306770
@arg_defaults=[nil, nil],
@arg_modes=[],
@arg_names=
[#<Piggly::Dumper::QualifiedName:0x00000101306ef0
@name="p_dmn",
@schema=nil>,
#<Piggly::Dumper::QualifiedName:0x00000101306e28
@name="p_firm_cmpst_score",
@schema=nil>],
@arg_types=
[#<Piggly::Dumper::QualifiedType:0x00000101306bf8
@name="risk.type_dmn",
@schema=nil>, #<= HERE
#<Piggly::Dumper::QualifiedType:0x00000101306b08
@name="risk.type_cmpst_firm_score[]",
@schema=nil>], #<= HERE
@identifier="9d72330dfcac0942efc7c7686a63cc24",
@name=
#<Piggly::Dumper::QualifiedName:0x00000101316490
@name="func_cmpst_store_firm_score",
@schema="risk">, Now that I have PostgreSQL installed locally I can work on confirming this and fixing it. Hopefully it'll be a quick fix and I can update the ticket tonight or tomorrow. |
@kputnam no worries. Thanks for taking the time to research this. I'm sure this will solve a host of issues for me. Could you build a new Gem once this fix is done? thanks! |
Ok, looks like the issue was that parameters with array types weren't correctly quoted: it should be |
Seems I was too quick to publish! I just noticed PostgreSQL complains if |
Ok, all set now |
thank you SO much! Will try first thing tomorrow |
Got the error below.
Initially thought I resolved by placing a space between "--" and "transfer" in the comment "--transfer last to past" but its just that piggly compiles the functions in different orders on different executions, and the error remains.
Might be due to "%rowtype" datatype. See belowThe text was updated successfully, but these errors were encountered: