从 MySQL 转换为 Postgres 并获取“产品”列不存在错误
我在 Rails 中使用acts_as_taggable_on，并试图获取所有尚未标记的产品的列表。在 MySQL 中，以下查询有效：
def self.untagged
available.find(:all,
:joins => %{LEFT JOIN taggings ON products.id = taggings.taggable_id AND taggings.taggable_type = "Product"},
:conditions => "taggings.id IS NULL AND for_sale IS true",
:order => "products.updated_at DESC"
)
但是，在 Postgres 中，我收到“Product”列不存在的错误。
生成的 SQL 似乎是：
SELECT count(*) AS count_all FROM "products" LEFT JOIN taggings ON products.id = taggings.taggable_id AND taggings.taggable_type = "Product" WHERE (taggings.id IS NULL AND for_sale IS true) AND (products.date_expires > '2011-09-12') )
关于如何使其工作有什么建议吗？我更喜欢使用活动记录友好的方式，这样它仍然可以在 MySQL 中工作。但这是我愿意牺牲的。
提前致谢..
I'm using acts_as_taggable_on in rails and I'm trying to get a listing of all Products that have yet to be tagged. In MySQL the following query worked:
def self.untagged
available.find(:all,
:joins => %{LEFT JOIN taggings ON products.id = taggings.taggable_id AND taggings.taggable_type = "Product"},
:conditions => "taggings.id IS NULL AND for_sale IS true",
:order => "products.updated_at DESC"
)
In Postgres, however, I get the error that the column "Product" does not exist.
The generated SQL appears to be:
SELECT count(*) AS count_all FROM "products" LEFT JOIN taggings ON products.id = taggings.taggable_id AND taggings.taggable_type = "Product" WHERE (taggings.id IS NULL AND for_sale IS true) AND (products.date_expires > '2011-09-12') )
Any suggestions on how to get this working? I'd prefer to use an active record friendly way so that it may still work in MySQL. But that's something I'd be willing to sacrifice.
Thanks in advance..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 PostgreSQL 中，您应该用单引号引用字符串文字，而不是双引号，双引号用于引用标识符（例如表名和列名）。 MySQL 倾向于对标准采取快速和宽松的态度，而 PostgreSQL 则倾向于更加严格。
You should be quoting string literals with single quotes in PostgreSQL, not double quotes, double quotes are for quoting identifiers (such as table and column names). MySQL tends to play fast and loose with the standards, PostgreSQL tends to be much stricter.