Skip site navigation (1) Skip section navigation (2)

Re: PROPOSAL of xmlvalidate

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tomáš Pospíšil <killteck(at)seznam(dot)cz>, pgsql-hackers(at)postgresql(dot)org, chmelab(at)gmail(dot)com
Subject: Re: PROPOSAL of xmlvalidate
Date: 2010-11-29 18:15:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Nov 29, 2010 at 12:56 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 11/29/2010 12:36 PM, Robert Haas wrote:
>> On Mon, Nov 29, 2010 at 12:18 PM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com>
>>  wrote:
>>> 2010/11/29 Robert Haas<robertmhaas(at)gmail(dot)com>:
>>>> On Sun, Nov 28, 2010 at 5:33 AM, Tomáš Pospíšil<killteck(at)seznam(dot)cz>
>>>>  wrote:
>>>>> I have idea of creating system table for holding DTDs, XSDs, Relax-NGs
>>>>> (similar as on ORACLE).
>>>>> Is that good idea?
>>>> I doubt it.  Why would we want to do that?
>>> If I understand, it allows a local copy of DTD, .. so then is possible
>>> to provide a fast DTD checking.
>> But that could equally well be stored in a user table rather than a
>> system table.
> Yeah. The trouble is you won't be able to use that reliably in a check
> constraint, which I imagine is one of the principal intended purposes. I'm
> not sure how we should go about that.

There is a whole category of things where you might want to write a
check constraint that involves accessing data in some other table, and
therefore it falls down because this makes the constraint
non-immutable.  But not infrequently one knows that, while in theory
the other table could change, in practice it will not, or only in ways
that won't cause the CHECK constraint to be violated.  We need to
think about a sensible way of handling this class of problems.
Putting the data into a system table doesn't really accomplish
anything; system tables aren't read-only either.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2010-11-29 18:19:35
Subject: compile error via SIOCGLIFCONF from ip.c on hpux-11
Previous:From: Robert HaasDate: 2010-11-29 18:10:45
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group