-
Notifications
You must be signed in to change notification settings - Fork 40
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
Support of Postgres < 8.2 #9
Comments
Hi @lc0 , This is quite a problem since I build this driver around PostgreSQL 9.4. I cannot see an easy way to support different version of drivers so would that be ok if you can just fork the project and remove that fields and all the references from key_column_usage.go? Sorry for that, :( |
that file is generated, right? What is the process there? Also how do you use this particular field? I can see the process, that people with different version could re-generate a driver around the use-case. |
Yeah, that file is generated so I didn't pick those fields but generated from the information_schema. I first create a raw-hand-written-sql version of the driver code and make all the generation work, then I use that code to generate the driver code, then replace the raw code with the generated code and toss away the raw code part. So it is kinda frozen code on that part since I have no way to go back, :) Any suggestions? |
If you describe your process of generation in detail I will try to generate it on my own. Right now, I started to change the file manually in order to get it running with Amazon Redshift. They use Postgres-compatible protocol, unfortunately, version is only 8.0.2. I solved issues with position_in_unique_constraint. There are some other limitations. For instance, currently I have the issue with:
|
Hi guys,
Thanks for the interesting project. Unfortunately, we have PostgreSQL version < 8.2, so we can't use position_in_unique_constraint.
modelq crashes with next error message:
I found, that these are generated in https://github.com/mijia/modelq/blob/master/drivers/postgres/key_column_usage.go#L24 What do you think is the best way to adapt this to my case?
Regards,
Sergii
The text was updated successfully, but these errors were encountered: