Re: Proposal for XML Schema Validation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal for XML Schema Validation
Date
Msg-id 18726.1376058932@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal for XML Schema Validation  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> On 08/09/2013 05:55 PM, Kodamasimham Pridhvi (MT2012066) wrote:
>> Only sole purpose of making use of keyword USE_SCHEMA is to mimic oracle (somewhere on
>> oracle site i found this type of syntax)

> Well, there's certainly precedent for that - see to_char, the various
> different BEGIN permutations, etc.

> I would suggest doing that as a second separate step though. First
> produce a function based interface that can be tried and tested without
> the need to mess with the syntax and the parser. Then once that's in
> good shape propose a patch that adds the compatibility syntax.

TBH I think any such syntax would be rejected.  We have enough trouble
dealing with the SQL standards committee's creative ideas about weird
syntax with unnecessary keywords.  Oracle compatibility is not going
to be enough of an argument for inventing another keyword.  Especially
not if it has to be reserved, which seems rather likely given where
you're proposing to put it.

Having to add another catalog column for the sole use of this feature is
another thing that's unlikely to fly.  (A general rule of thumb is that
if a proposed feature imposes overhead on everybody, whether they ever
use that feature or not, it had better be something that a pretty large
percentage of people *will* use.  I doubt this meets that standard.)

So if you can do it along the lines of CHECK(xml_validates(xml_col_name,
'schema name')), I would strongly urge you to pursue that path.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: mvcc catalo gsnapshots and TopTransactionContext
Next
From: David Fetter
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])