On 24 October 2012 18:17, Tom Lane t...@sss.pgh.pa.us wrote:
Marco Nenciarini marco.nenciar...@2ndquadrant.it 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
Thom Brown wrote:
On 24 October 2012 18:17, Tom Lane t...@sss.pgh.pa.us wrote:
Marco Nenciarini marco.nenciar...@2ndquadrant.it 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,
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 wanted
On 25 October 2014 13:28, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Thom Brown wrote:
On 24 October 2012 18:17, Tom Lane t...@sss.pgh.pa.us wrote:
Marco Nenciarini marco.nenciar...@2ndquadrant.it writes:
Please find the attached refreshed patch (v2) which fixes the loose
ends
On 25 October 2014 19:19, Thom Brown t...@linux.com wrote:
On 25 October 2014 13:28, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Thom Brown wrote:
On 24 October 2012 18:17, Tom Lane t...@sss.pgh.pa.us wrote:
Marco Nenciarini marco.nenciar...@2ndquadrant.it writes:
Please find the
On Wed, Oct 24, 2012 at 12:06:35PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
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 FROM
Noah Misch n...@leadboat.com 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,
Marco Nenciarini marco.nenciar...@2ndquadrant.it 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
On 10/22/12 4:22 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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
where
2012/10/22 Tom Lane t...@sss.pgh.pa.us:
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
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
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 the
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
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Oct 22, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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.
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.
Andrew Dunstan and...@dunslane.net 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
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
On Fri, Oct 19, 2012 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us 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
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com 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
On Fri, Oct 19, 2012 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us 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
Claudio Freire klaussfre...@gmail.com writes:
What about something more generic?
CREATE TABLE tname ( cname type [(expr)] REFERENCES t2name
[(t2expr)] )
Meaning, if expr is missing, it's taken expr = cname, if not,
it's the result of that expression the one that references the target
Andres Freund and...@2ndquadrant.com 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:
On 10/19/2012 04:40 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Marco Nenciarini marco.nenciar...@2ndquadrant.it 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
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
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:
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
33 matches
Mail list logo
