Re: PostgreSQL vs SQL Standard

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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