Andrew Gierth <and...@tao11.riddles.org.uk> writes: > I created this wiki page: > https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL_Standard
Good idea! > I think I got all the issues I currently know of, but there may be > more, and others may disagree with my classification of issues or the > rationales for violating the spec. Any feedback? WRT 1.1 ... I doubt that redefining DROP DOMAIN as you describe has "no major issues". It sounds to me like an incredibly ugly wart on the cascaded dependency logic. Quite aside from wartiness, adding new objects/dependencies as part of a DROP is broken by design. What if the domain drop has cascaded from something the domain's constraints themselves depend on? I'd put this as a "has design-level problems" item. WRT 3.2 on select-list aliases, the postfix-operator issue is only one of several reasons why we can't support that. There was some more-detailed discussion about that awhile back, https://www.postgresql.org/message-id/flat/99ad0450-b1ab-702f-48ef-6972b630bc87%40BlueTreble.com Constraint name scope: I think it's an overstatement to say that this makes some info-schema views "useless". "Under-determined" might be an appropriate word. Or you could say "useless unless the application limits itself to follow the SQL spec's restriction on names". Object ownership scope: I have not really dug into the spec on this point, but I recall from our own docs that "schema owner owns all contained objects too" is true only in DBs that implement some minimal subset of the standard. So that might need more explanation. In any case, we can surely mount a very strong defense in terms of usability/flexibility here, we don't need to say it's just historical. regards, tom lane
