On 25 October 2014 19:19, Thom Brown wrote:
> On 25 October 2014 13:28, Alvaro Herrera wrote:
>
>> Thom Brown wrote:
>> > On 24 October 2012 18:17, Tom Lane wrote:
>> >
>> > > Marco Nenciarini writes:
>> > > > Please find the attached refreshed patch (v2) which fixes the loose
>> ends
>> > > >
On 25 October 2014 13:28, Alvaro Herrera wrote:
> Thom Brown wrote:
> > On 24 October 2012 18:17, Tom Lane wrote:
> >
> > > Marco Nenciarini writes:
> > > > Please find the attached refreshed patch (v2) which fixes the loose
> ends
> > > > you found.
> > >
> > > Attached is a v3 patch that upda
Alvaro Herrera wrote:
> Thom Brown wrote:
> > Does anyone have any intention of resurrecting this at this stage?
>
> Not in this room. Do you?
I should have added some more context so that people realizes that "this
room" contains the 2ndQuadrant people involved in writing this patch.
Also I wa
Thom Brown wrote:
> On 24 October 2012 18:17, Tom Lane wrote:
>
> > Marco Nenciarini writes:
> > > Please find the attached refreshed patch (v2) which fixes the loose ends
> > > you found.
> >
> > Attached is a v3 patch that updates the syntax per discussion, uses what
> > seems to me to be a sa
On 24 October 2012 18:17, Tom Lane wrote:
> Marco Nenciarini writes:
> > Please find the attached refreshed patch (v2) which fixes the loose ends
> > you found.
>
> Attached is a v3 patch that updates the syntax per discussion, uses what
> seems to me to be a saner (more extensible) catalog repr
On Wed, Oct 24, 2012 at 12:06:35PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > For FKs, we currently document that "The referenced columns must be the
> > columns of a non-deferrable unique or primary key constraint in the
> > referenced
> > table." Taking that literally, one might imagine t
Marco Nenciarini writes:
> Please find the attached refreshed patch (v2) which fixes the loose ends
> you found.
Attached is a v3 patch that updates the syntax per discussion, uses what
seems to me to be a saner (more extensible) catalog representation, and
contains assorted other code cleanup.
Noah Misch writes:
> For FKs, we currently document that "The referenced columns must be the
> columns of a non-deferrable unique or primary key constraint in the referenced
> table." Taking that literally, one might imagine that bare UNIQUE indexes do
> not qualify. However, transformFkeyCheckA
On Wed, Oct 24, 2012 at 12:36:31AM -0400, Tom Lane wrote:
> The proposed patch uses this if the referencing column is an array:
>
> SELECT 1 WHERE
> (SELECT pg_catalog.count(DISTINCT y) FROM pg_catalog.unnest($1) y)
> OPERATOR(pg_catalog.=)
> (SELECT pg_catalog.count(*) FROM
> (SELECT 1
Now that it seems like we've got consensus on syntax, let's talk about
some implementation issues.
Ordinarily, the query executed during an insert or update on the
referencing table looks like, for example,
SELECT 1 FROM ONLY "public"."pk" x
WHERE "f1" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x
On 10/22/12 4:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I think if that's the best we can do, you original proposal of
>> ditching the column constraint syntax altogether might be for the
>> best. I wasn't too excited about that before, but I think having two
>> different syntaxes is
Robert Haas writes:
> Well, I think if that's the best we can do, you original proposal of
> ditching the column constraint syntax altogether might be for the
> best. I wasn't too excited about that before, but I think having two
> different syntaxes is going to be even worse. In some ways, it's
On Mon, Oct 22, 2012 at 2:29 PM, Tom Lane wrote:
> I'm not thrilled with the inconsistency either, but given the
> constraints we're under, it seems like the best we can do. (I feel,
> as Andrew does, that shoving WHERE into the table-constraint syntax
> would not be an improvement; but the colum
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane wrote:
> I wrote:
>> I tested, and indeed this seems to work:
>> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
>> and it's perfectly sensible from an English-grammar standpoint too.
>> If we take that, how would we spell the table-cons
Robert Haas writes:
> On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane wrote:
>> I wrote:
>>> I tested, and indeed this seems to work:
>>> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
>>> and it's perfectly sensible from an English-grammar standpoint too.
>>> If we take that, how would w
On 10/22/2012 12:13 PM, Andres Freund wrote:
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
> I wrote:
> > I tested, and indeed this seems to work:
> > CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
> >
> > and it's perfectly sensible from an English-grammar standpoint too.
> > If we take that, how would we spell th
On 10/22/2012 12:08 PM, Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the table-constraint case exactly
2012/10/22 Tom Lane :
> I wrote:
>> I tested, and indeed this seems to work:
>> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
>> and it's perfectly sensible from an English-grammar standpoint too.
>> If we take that, how would we spell the table-constraint case exactly?
>> Gramm
I wrote:
> I tested, and indeed this seems to work:
> CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
> and it's perfectly sensible from an English-grammar standpoint too.
> If we take that, how would we spell the table-constraint case exactly?
> Grammatically I'd prefer
> F
On 10/19/2012 04:40 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 10/19/2012 03:55 PM, Tom Lane wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so "EACH ELEMENT REFERENCES" still isn't gonna work. I'
Andres Freund writes:
> What about sticking a WHERE in there? I.e. FOREIGN KEY (foo, WHERE EACH
> ELEMENT OF bar) ...
Well, we don't really need it in the table-constraint case. The
column-constraint case is the sticking point.
I tested, and indeed this seems to work:
CREATE TABLE t1
Claudio Freire writes:
> What about something more generic?
> CREATE TABLE ( [()] REFERENCES
> [()] )
> Meaning, if is missing, it's taken = , if not,
> it's the result of that expression the one that references the target
> table.
Doesn't seem terribly sensible as a column constraint: a
On Friday, October 19, 2012 09:55:10 PM Tom Lane wrote:
> FOREIGN KEY (foo, EACH ELEMENT OF bar) REFERENCES ...
>
> which is certainly more verbose than just "ELEMENT" but I think it
> makes it clearer that each array element is required to have a match
> separately. If we ever implemente
On Fri, Oct 19, 2012 at 5:48 PM, Tom Lane wrote:
> It looks like we could support
>
> CREATE TABLE t1 (c int[] REFERENCES BY ELEMENT t2);
>
> but (1) this doesn't seem terribly intelligible to me, and
> (2) I don't see how we modify that if we want to provide
> at-least-one-match semantics
Robert Haas writes:
> This is a little sneaky, but I presume you only get the grammar
> conflict if you try to sneak the "each" or "element" or "each element"
> or whatever-you-call-it designator in BEFORE the column name. So what
> about just putting it afterwards? Something like this:
> FOREI
Andrew Dunstan writes:
> On 10/19/2012 03:55 PM, Tom Lane wrote:
>> That doesn't get us any closer to having a working column-constraint
>> syntax unfortunately, because EACH is not a reserved word either
>> so "EACH ELEMENT REFERENCES" still isn't gonna work. I'm getting
>> more willing to give
On Fri, Oct 19, 2012 at 3:55 PM, Tom Lane wrote:
> That doesn't get us any closer to having a working column-constraint
> syntax unfortunately, because EACH is not a reserved word either
> so "EACH ELEMENT REFERENCES" still isn't gonna work. I'm getting
> more willing to give up on having a colum
On 10/19/2012 03:55 PM, Tom Lane wrote:
This thought also crystallizes something else that had been bothering me,
which is that "ELEMENT" alone is a pretty bad choice of syntax because
it entirely fails to make clear which of these semantics is meant.
I'm tempted to propose that we use
Andrew Dunstan writes:
> I'm late to this party, so I apologize in advance if this has already
> been considered, but do we actually need a special syntax? Can't we just
> infer that we have one of these when the referring column is an array
> and the referenced column is of the base type of th
On 10/18/2012 10:26 PM, Tom Lane wrote:
Another possibility is to forget about the column constraint ELEMENT
REFERENCES syntax, and only support the table-constraint syntax with
ELEMENT inside the column list --- I've not checked, but I think that
syntax doesn't have any ambiguity problems.
Or
I wrote:
> Or we could go back to using ARRAY here --- that should be safe since
> ARRAY is already fully reserved.
Ugh ... no, that doesn't work, because ARRAY[...] is allowed in c_expr
and hence b_expr. So the ambiguity would still be there. We'd need a
different fully-reserved keyword to go t
Marco Nenciarini writes:
> Please find the attached refreshed patch (v2) which fixes the loose ends
> you found.
I've started looking at this patch, and the first thing I notice is that
the syntax doesn't work. It's ambiguous, and this:
%left JOIN CROSS LEFT FULL RIGHT INNER_P NATURAL
Thanks for your review.
Please find the attached refreshed patch (v2) which fixes the loose ends
you found.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Array-ELEMENT-foreign-key-v2.patc
On Tue, Sep 18, 2012 at 05:52:51PM +0200, Marco Nenciarini wrote:
> please find attached the refreshed v1 patch.
I perused this version in comparison to the last version I reviewed, finding
minor problems. First, a warning:
tablecmds.c: In function `ATExecAddConstraint':
tablecmds.c:5898: wa
Hi,
please find attached the refreshed v1 patch.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Array-ELEMENT-foreign-key-v1-refreshed.patch.bz2
Description: application/bzip
--
Sent
Hi,
please find attached version 1 of the patch introducing "Array
ELEMENT Foreign Keys" support. This new thread and related patch
substitute any previous discussion about "Support for foreign keys with
arrays", as anticipated in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg01098.ph
37 matches
Mail list logo
