LIKE/ESCAPE et al, initdb required!

Started by Thomas Lockhartover 25 years ago4 messages
#1Thomas Lockhart
lockhart@alumni.caltech.edu

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.

#2Zeugswetter Andreas SB
ZeugswetterA@wien.spardat.at
In reply to: Thomas Lockhart (#1)
AW: LIKE/ESCAPE et al, initdb required!

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

#3Thomas Lockhart
lockhart@alumni.caltech.edu
In reply to: Zeugswetter Andreas SB (#2)
Re: AW: LIKE/ESCAPE et al, initdb required!

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

#4The Hermit Hacker
scrappy@hub.org
In reply to: Thomas Lockhart (#3)
Re: AW: LIKE/ESCAPE et al, initdb required!

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*