Since nobody has told me why my proposal doesn't work, I figure I will
point out that it does solve this problem nicely. However, it makes the
assumptions that we treat the identifiers as quoted when the backend
uses them to look them up in the system catalogs. Also I am rethinking
a few details.... I make the following assumptions:
1) All backend references to identifiers are treated as quoted by the
backend as mentioned in a previous thread.
2) Same with official clients like psql.
3) We don't guarantee complete backward compatibility in the system
catalogs anyway (note that this is a trivial problem to solve if 1 above
is solved-- schemas, views, and rules can accomplish some cool tricks
:-) ).
If these are not done, then it would be too much work to do at the
moment even if a customer required it. However, if this is the case, we
need to get these areas done first (they probably should be done anyway).
Quite frankly if system catalog backwards-compatibility is that much of
an issue for people, if others commit to the rest of the work, I will be
happy to create a PG_CATALOG schema with views off pg_catalog.... All
then that we need to do is to put it in the search path :-) Oh, and the
same for information_schema and INFORMATION_SCHEMA tool.
Okay, how do we refer to the "RI_FKey_cascade_del" function then? Or
trigger "RI_ConstraintTrigger_2204908". Using $$ quoting? Invent
another quoting style?
Right, and when we start reqiring non-standard quoting styles, then we
are not standards-compliant either :-)
Also it occurs to me that we that there are three options for dealing
with case issues. These do *not* need to be done at the parser level as
long as the backend treats catalog identifiers as previously quoted.
But there are really two options...
1) Try to differentiate between function names and aggregates in the
parser. This seems like a non-starter to me. But if I am missing
something I am open to suggestions....
2) My original idea of duplicate catalog entries. I.e. one for "MAX"
and one for "max" Again, I am willing to do this work if people decide
that they are going to go ahead and try to get this in the next release.
Best Wishes,
Chris Travers
Metatron Technology Consulting
begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@xxxxxxxxxxxxxxxx
x-mozilla-html:FALSE
version:2.1
end:vcard
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
