Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So should I set up a nested scan, essentially implementing a nested loop? or
> > should I gather together all the children in a list?
>
> I'd use the predigested form of the constraints attached to the Relation
> t
Greg Stark <[EMAIL PROTECTED]> writes:
> So I'm thinking it's better to leave my implementation as is rather than
> reimplement it using the relcache. Or would it be better to use the relcache
> and then when and if it comes to making inherited tables inherit foreign key
> constraints look into add
Pavel Stehule wrote:
> Hello
> >
> >If there were a serious amount of demand for the SQL2003 XML features
> >then I wouldn't be averse to putting them in, but right now it looks
> >like bloat with little redeeming social value. Who other than the
> >submitter has asked for this? I don't even see
Tom Lane wrote:
> If there were a serious amount of demand for the SQL2003 XML features
> then I wouldn't be averse to putting them in, but right now it looks
> like bloat with little redeeming social value. Who other than the
> submitter has asked for this? I don't even see "XML" listed in TODO.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There have been inquiries about some kind of XML support every few weeks
> for years now. Clearly, we need to sort out what that really means.
Agreed. We need a road map of some sort.
> I'm preparing a session about that for the Toronto summit.
OK, but it seemed the patch needed more work before it could be applied.
I added a TODO item for it:
o Allow PL/RETURN to return row or record functions
http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
---
Tom Lane <[EMAIL PROTECTED]> writes:
> If you're happy with the code looking directly at pg_constraint then
> I see no reason to change it. I just mentioned the relcache because
> I thought you were concerned about the performance of a pg_constraint
> search.
I'm not concerned with the performan
I'm finally getting back to looking at the problem of reference-counting
cached TupleDescs as was discussed in January. I had objected to the
last patch Neil posted:
http://archives.postgresql.org/pgsql-patches/2006-01/msg00243.php
on the grounds that it seemed too complicated. On looking at it
c
Patch applied. Thanks.
---
Bruce Momjian wrote:
>
> I have modified your patch (attached) and will apply soon, unless there
> are more community comments. Thanks.
>
>
I'll prepare some classification of differend kinds of XML support,
including a brief overview for oracle, sql server and db2 (I'm a
person who works on that SoC project)
As for Pavel's patch, I think it's pretty complete piece of several
SQL/XML functions and could be usefull for people (e.g for
This is a revised fillfactor patch. It uses WITH syntax and
we can add new AM specific parameters easily.
Simon Riggs <[EMAIL PROTECTED]> wrote:
> I see what Tom was driving at with earlier comments. I think we need an
> non-index AM specific patch, so that each AM has its own parameters.
I add
Tom has some objectives to state PL/pgSQL not explicitly into patch if I
remeber well. If I get comments, I'll correct patch promptly.
Pavel
OK, but it seemed the patch needed more work before it could be applied.
I added a TODO item for it:
o Allow PL/RETURN to return row or record func
12 matches
Mail list logo
