On Fri, Jul 4, 2014 at 12:36 AM, Rushabh Lathia
rushabh.lat...@gmail.com wrote:
On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tom Dunstan pg...@tomd.cc writes:
On 4 July 2014 00:07, Tom Lane t...@sss.pgh.pa.us wrote:
It sounds to me like designing this for JDBC's
On Mon, Jul 7, 2014 at 5:50 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 4, 2014 at 12:36 AM, Rushabh Lathia
rushabh.lat...@gmail.com wrote:
On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tom Dunstan pg...@tomd.cc writes:
On 4 July 2014 00:07, Tom Lane
On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick i...@2ndquadrant.com wrote:
On 01/07/14 21:00, Rushabh Lathia wrote:
I spent some more time on the patch and here are my review comments.
.) Patch gets applied through patch -p1 (git apply fails)
.) trailing whitespace in the patch at various
Rushabh Lathia rushabh.lat...@gmail.com writes:
On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick i...@2ndquadrant.com wrote:
A better solution would be to have an optional IF EXISTS clause:
RETURNING PRIMARY KEY [ IF EXISTS ]
Hmm liked the idea about adding [ IF EXISTS ]. Looking at the grammar so
On Thu, Jul 3, 2014 at 7:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy
in that the application would have little idea what it was getting back.
IF EXISTS would make it so spongy as to be useless, IMO.
Seems easy enough to look at
Greg Stark st...@mit.edu writes:
On Thu, Jul 3, 2014 at 7:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy
in that the application would have little idea what it was getting back.
IF EXISTS would make it so spongy as to be useless,
On 4 July 2014 00:07, Tom Lane t...@sss.pgh.pa.us wrote:
TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy
in that the application would have little idea what it was getting back.
IF EXISTS would make it so spongy as to be useless, IMO.
IF EXISTS is pretty pointless - while
Tom Dunstan pg...@tomd.cc writes:
On 4 July 2014 00:07, Tom Lane t...@sss.pgh.pa.us wrote:
It sounds to me like designing this for JDBC's getGeneratedKeys method
is a mistake. There isn't going to be any way that the driver can support
that without having looked at the table's metadata for
On 4 July 2014 11:37, Tom Lane t...@sss.pgh.pa.us wrote:
Sure it can - it append RETURNING PRIMARY KEY and hand back a ResultSet
from whatever was returned. It's CURRENTLY doing that, but it's appending
RETURNING * and leaving it up to the caller of getGeneratedKeys() to work
out which
On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tom Dunstan pg...@tomd.cc writes:
On 4 July 2014 00:07, Tom Lane t...@sss.pgh.pa.us wrote:
It sounds to me like designing this for JDBC's getGeneratedKeys method
is a mistake. There isn't going to be any way that the
On 14/07/01 23:13, Robert Haas wrote:
On Tue, Jul 1, 2014 at 8:00 AM, Rushabh Lathia rushabh.lat...@gmail.com
wrote:
.) In map_primary_key_to_list() patch using INDEX_ATTR_BITMAP_IDENTITY_KEY
bitmap to get the keycols. In IndexAttrBitmapKind there is also
INDEX_ATTR_BITMAP_KEY, so was
On 02/07/14 15:16, Ian Barwick wrote:
On 14/07/01 23:13, Robert Haas wrote:
On Tue, Jul 1, 2014 at 8:00 AM, Rushabh Lathia rushabh.lat...@gmail.com wrote:
.) In map_primary_key_to_list() patch using INDEX_ATTR_BITMAP_IDENTITY_KEY
bitmap to get the keycols. In IndexAttrBitmapKind there is also
On 01/07/14 21:00, Rushabh Lathia wrote:
I spent some more time on the patch and here are my review comments.
.) Patch gets applied through patch -p1 (git apply fails)
.) trailing whitespace in the patch at various places
Not sure where you see this, unless it's in the tests, where it's
I spent some more time on the patch and here are my review comments.
.) Patch gets applied through patch -p1 (git apply fails)
.) trailing whitespace in the patch at various places
.) Unnecessary new line + and - in the patch.
(src/backend/rewrite/rewriteManip.c::getInsertSelectQuery())
On Tue, Jul 1, 2014 at 8:00 AM, Rushabh Lathia rushabh.lat...@gmail.com wrote:
.) In map_primary_key_to_list() patch using INDEX_ATTR_BITMAP_IDENTITY_KEY
bitmap to get the keycols. In IndexAttrBitmapKind there is also
INDEX_ATTR_BITMAP_KEY, so was confuse between INDEX_ATTR_BITMAP_KEY and
Thanks for sharing latest patch.
For me this syntax is limiting the current returning clause implementation.
Because its not allowing the returning PRIMARY KEYS with other columns, and
if user or application require that they need to do RETURNING *. Following
syntax not working, which i think is
On 27/06/14 00:12, Rushabh Lathia wrote:
Thanks for sharing latest patch.
For me this syntax is limiting the current returning clause
implementation.
Because its not allowing the returning PRIMARY KEYS with other
columns, and
if user or application require that they need to do RETURNING *.
On 27 June 2014 06:14, Gavin Flower gavinflo...@archidevsys.co.nz wrote:
On 27/06/14 00:12, Rushabh Lathia wrote:
INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning primary
key, dname;
I think allowing other columns with PRIMARY KEY would be more useful
syntax.
Even in later
On 27/06/14 09:09, Tom Dunstan wrote:
On 27 June 2014 06:14, Gavin Flower gavinflo...@archidevsys.co.nz
mailto:gavinflo...@archidevsys.co.nz wrote:
On 27/06/14 00:12, Rushabh Lathia wrote:
INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning primary
key, dname;
Hello All,
I assigned my self as reviewer of the patch. I gone through the
mail chain discussion and in that question has been raised about
the feature and its implementation, so would like to know what is
the current status of this project/patch.
Regards,
On Thu, Jun 12, 2014 at 5:53 PM, Ian
Hi
On 14/06/25 15:13, Rushabh Lathia wrote:
Hello All,
I assigned my self as reviewer of the patch. I gone through the
mail chain discussion and in that question has been raised about
the feature and its implementation, so would like to know what is
the current status of this
On 25/06/14 16:04, Ian Barwick wrote:
Hi
On 14/06/25 15:13, Rushabh Lathia wrote:
Hello All,
I assigned my self as reviewer of the patch. I gone through the
mail chain discussion and in that question has been raised about
the feature and its implementation, so would like to know what is
the
On Wed, Jun 11, 2014 at 2:39 AM, Tom Lane wrote:
I'm not even 100% sold that automatically returning the primary key
is going to save any application logic. Could somebody point out
*exactly* where an app is going to save effort with this type of
syntax, compared to requesting the columns it
On 14/06/12 18:46, Jochem van Dieten wrote:
On Wed, Jun 11, 2014 at 2:39 AM, Tom Lane wrote:
I'm not even 100% sold that automatically returning the primary key
is going to save any application logic. Could somebody point out
*exactly* where an app is going to save effort with
On Thu, Jun 12, 2014 at 12:25 PM, Ian Barwick wrote:
On 14/06/12 18:46, Jochem van Dieten wrote:
I haven't checked the code, but I am hoping it will help with the problem
where a RETURNING * is added to a statement that is not an insert or
update
by the JDBC driver. That has been reported
On 2014-06-12 13:58:31 +0200, Jochem van Dieten wrote:
But the obvious way to fix the JDBC issue is not to fix it by adding a
'mini parser' on the JDBC side, but to make SELECT ... RETURNING PRIMARY
KEY a regular select that silently ignores the returning clause and doesn't
throw an error on
On 14/06/12 20:58, Jochem van Dieten wrote:
On Thu, Jun 12, 2014 at 12:25 PM, Ian Barwick wrote:
On 14/06/12 18:46, Jochem van Dieten wrote:
I haven't checked the code, but I am hoping it will help with the
problem
where a RETURNING * is added to a statement that is not an
On 06/10/2014 03:19 AM, Tom Dunstan wrote:
A definite +1 on this feature. A while ago I got partway through
hacking the hibernate postgres dialect to make it issue a RETURNING
clause to spit out the primary key before I realised that the driver
was already doing a RETURNING * internally.
On
On 10 June 2014 17:49, Hannu Krosing ha...@2ndquadrant.com wrote:
RETURNING GENERATED KEYS perhaps, but then how do we determine that?
What about RETURNING CHANGED FIELDS ?
Might be quite complicated technically, but this is what is probably
wanted.
Seems to be getting further away from
On 06/10/2014 11:02 AM, Tom Dunstan wrote:
On 10 June 2014 17:49, Hannu Krosing ha...@2ndquadrant.com
mailto:ha...@2ndquadrant.com wrote:
RETURNING GENERATED KEYS perhaps, but then how do we determine that?
What about RETURNING CHANGED FIELDS ?
Might be quite complicated
On 06/09/2014 07:13 PM, Andres Freund wrote:
On 2014-06-09 13:42:22 +0200, Vik Fearing wrote:
On 06/09/2014 09:06 AM, Gavin Flower wrote:
From memory all unique keys can be considered 'candidate primary keys',
but only one can be designated 'the PRIMARY KEY'.
Almost. Candidate keys are also
On 2014-06-11 00:21:58 +0200, Vik Fearing wrote:
On 06/09/2014 07:13 PM, Andres Freund wrote:
On 2014-06-09 13:42:22 +0200, Vik Fearing wrote:
On 06/09/2014 09:06 AM, Gavin Flower wrote:
From memory all unique keys can be considered 'candidate primary keys',
but only one can be designated
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-11 00:21:58 +0200, Vik Fearing wrote:
What? AFAIK, that only applies to an index. How can the data itself be
partial?
I don't follow? Gavin above talked about unique keys - which in postgres
you can create using CREATE UNIQUE INDEX.
On 11 June 2014 10:09, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not even 100% sold that automatically returning the primary key
is going to save any application logic. Could somebody point out
*exactly* where an app is going to save effort with this type of
syntax, compared to requesting the
Is it going to save enough to justify depending on a syntax that won't
be universal for a long time to come?
Oh, and on the won't-be-universal-for-a-while point - the status quo works
fine, it's just less efficient than it should be. Once someone upgrades to
9.5 or whatever, and upgrades to
David G Johnston wrote
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of
retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
significant
On 09/06/14 14:47, David G Johnston wrote:
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
On Monday, June 9, 2014, Ian Barwick i...@2ndquadrant.com wrote:
On 09/06/14 14:47, David G Johnston wrote:
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of
retrieving
primary key values without the need to explicitly specify the primary key
On 09/06/14 17:47, David G Johnston wrote:
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
On 06/09/2014 09:06 AM, Gavin Flower wrote:
From memory all unique keys can be considered 'candidate primary keys',
but only one can be designated 'the PRIMARY KEY'.
Almost. Candidate keys are also NOT NULL.
--
Vik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
David G Johnston david.g.johns...@gmail.com wrote:
ERROR: Relation does not have any primary key(s)
Relation does not have a primary key.
or
Relation has no primary key. (preferred)
Project style says that the primary message should not capitalize
the first word, nor should it end in
On 06/09/2014 06:58 AM, Ian Barwick wrote:
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of
retrieving
primary key values without the need to explicitly specify the primary key
column(s).
Is it defined by the standard, to return _only_ generated primary keys,
and not
for
Ian Barwick i...@2ndquadrant.com writes:
[ RETURNING PRIMARY KEY ]
It looks to me like this is coded to have the expansion of the primary
key done at parse time, which seems like fundamentally the wrong thing.
Consider a view or rule containing this clause; the pkey might be
different by the
On 09/06/14 23:42, Vik Fearing wrote:
On 06/09/2014 09:06 AM, Gavin Flower wrote:
From memory all unique keys can be considered 'candidate primary keys',
but only one can be designated 'the PRIMARY KEY'.
Almost. Candidate keys are also NOT NULL.
Yeah, obviously!
(Except, I did actually
On 2014-06-09 13:42:22 +0200, Vik Fearing wrote:
On 06/09/2014 09:06 AM, Gavin Flower wrote:
From memory all unique keys can be considered 'candidate primary keys',
but only one can be designated 'the PRIMARY KEY'.
Almost. Candidate keys are also NOT NULL.
The list actually is a bit
On 6/9/14, 8:35 AM, Hannu Krosing wrote:
On 06/09/2014 06:58 AM, Ian Barwick wrote:
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of
retrieving
primary key values without the need to explicitly specify the primary key
column(s).
Is it defined by the standard, to return
A definite +1 on this feature. A while ago I got partway through hacking
the hibernate postgres dialect to make it issue a RETURNING clause to spit
out the primary key before I realised that the driver was already doing a
RETURNING * internally.
On 10 June 2014 05:53, Jim Nasby j...@nasby.net
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
significant
performance drawbacks.
Currently this feature is
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
significant
performance drawbacks.
49 matches
Mail list logo
