LIKE/ESCAPE et al, initdb required!
I've bumped the system catalog version number and committed changes
which:
o implement LIKE/ESCAPE and related clauses
o implement a case-insensitive ILIKE and related clauses
o allow embedded double-quotes in double-quoted identifers
o implement CREATE/DROP SCHEMA as a synonym for CREATE DATABASE
All (more or less ;) per SQL99 standard, with the SCHEMA stuff just a
stopgap (afaik others are planning real work in this area). A few other
fixups too...
- Thomas
From the CVS logs:
Support SQL99 embedded double-quote syntax for quoted identifiers.
Allow this in the parser and in pg_dump, but it is probably not enough
for a complete solution.
Better to have the feature started then never here.
Implement LIKE/ESCAPE. Change parser to use like()/notlike()
rather than the "~~" operator; this made it easy to add ESCAPE
features.
Implement ILIKE, NOT ILIKE, and the ESCAPE clause for them.
afaict this is not MultiByte clean, but lots of other stuff isn't
either.
Fix up underlying support code for LIKE/NOT LIKE.
Things should be faster and does not require internal string copying.
Update regression test to add explicit checks for
LIKE/NOT LIKE/ILIKE/NOT ILIKE.
Remove colon and semi-colon operators as threatened in 7.0.
Implement SQL99 COMMIT/AND NO CHAIN.
Throw elog(ERROR) on COMMIT/AND CHAIN per spec
since we don't yet support it.
Implement SQL99 CREATE/DROP SCHEMA as equivalent to CREATE DATABASE.
This is only a stopgap or demo since schemas will have another
implementation soon.
Remove a few unused production rules to get rid of warnings
which crept in on the last commit.
Fix up tabbing in some places by removing embedded spaces.
I've bumped the system catalog version number and committed changes
which:
o implement CREATE/DROP SCHEMA as a synonym for CREATE DATABASE
This is imho wrong !
Please do not preassume results to a discussion that is not over or has
not reached a consensus.
Some of us (me) where of the opinion that schema must be a hierarchy below
our database.
Access to different schemas within one session is mandatory.
Non default schemas need to be syntactically specified with:
schemaname.tabname
So I ask you to please revert the above change unless we reach a consensus.
Andreas
Import Notes
Resolved by subject fallback
So I ask you to please revert the above change unless we reach a consensus.
Don't panic! I did this with the *explicit* mention that it is a
stopgap, and it does not preclude the better long term solution which
you have been discussing. The CVS log reflects this, as does my
announcement to the list.
This will be an unannounced feature in our next release (if at all), so
folks can't claim to have grown fond of it ;)
- Thomas
On Mon, 7 Aug 2000, Thomas Lockhart wrote:
So I ask you to please revert the above change unless we reach a consensus.
Don't panic! I did this with the *explicit* mention that it is a
stopgap, and it does not preclude the better long term solution which
you have been discussing. The CVS log reflects this, as does my
announcement to the list.This will be an unannounced feature in our next release (if at all), so
folks can't claim to have grown fond of it ;)
So, if its a stopgap and won't be announced ... why implement it? *raised
eyebrow* *grin*