Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id EEBAF6324A7 for ; Mon, 1 Feb 2010 00:27:49 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 37887-07 for ; Mon, 1 Feb 2010 04:27:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mail.postgresql.org (Postfix) with SMTP id D581562DBF0 for ; Mon, 1 Feb 2010 00:27:38 -0400 (AST) Received: (qmail invoked by alias); 01 Feb 2010 04:27:36 -0000 Received: from i59F79B56.versanet.de (EHLO [192.168.1.113]) [89.247.155.86] by mail.gmx.net (mp013) with SMTP; 01 Feb 2010 05:27:36 +0100 X-Authenticated: #14269776 X-Provags-ID: V01U2FsdGVkX1+BXkVMd6eBMmLre8aergHb0SaH5jfstMb6xgPlMI QKThK7zVsdc2gq Message-ID: <4B66583C.1050708@gmx.net> Date: Mon, 01 Feb 2010 05:27:40 +0100 From: Andreas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Lane CC: Joshua Tolley , pgsql-sql@postgresql.org Subject: Re: Howto have a unique restraint on UPPER (textfield) References: <4B64EA46.60605@gmx.net> <4b64f184.9613f30a.5d13.01b2@mx.google.com> <4B65EC9C.6000606@gmx.net> <16294.1264972066@sss.pgh.pa.us> In-Reply-To: <16294.1264972066@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67000000000000004 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.855 tagged_above=-10 required=5 tests=AWL=-0.745, BAYES_05=-1.11 X-Spam-Level: X-Archive-Number: 201002/2 X-Sequence-Number: 33601 Tom Lane schrieb: > Andreas writes: > >> So I had the missconception that UNIQUE (...) within CREATE TABLE (...) >> was actually just an shorter way to define a unique index which it is not. >> > > Well, it is that --- it just doesn't provide access to all the features > that CREATE INDEX does. > So as it is a shortcut for "create index" then why would the function call of upper not be accepted when the sql parser maps the uniqe-constraint into the "create index" command? The parser could just take everything in the ( ) and use it as is. Somehow there must be a notice in the meta data to mark the difference. pgAdmin shows a unique as constraint but no index when created within "create table". The unique-index only shows up when created seperately. regards Andreas