From: | "Igal (at) Lucee(dot)org" <igal(at)lucee(dot)org> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: RETURNING primary_key() |
Date: | 2016-03-07 20:51:26 |
Message-ID: | 56DDE9CE.3000006@lucee.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/7/2016 12:45 PM, Joshua D. Drake wrote:
>
> I agree that the problem is that you don't always know what the
> primary key is.
>
> I would argue the solution is to check before you write the query.
Sure, that would be great, but perhaps I should have give some more context:
We have an application server which allows our developers to query
databases with simplified syntax. Our code is written in a generic way
to allow the developers that use our application server to pass whatever
query they want into the database server, whether it's SQL Server,
MySQL, Oracle, etc.
The code that we use to wrap the SQL statement, as well as the JDBC
code, has no idea about the table or its constraints, so it's not like
I'm writing my own queries, and am just being lazy at checking what the
primary key is. I just can't know what the developer has in his database.
Sure, I can probably query it via metadata tables, etc., but that would
be a much slower process.
Igal
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitrii Golub | 2016-03-07 20:55:19 | Re: unexpected result from to_tsvector |
Previous Message | Joshua D. Drake | 2016-03-07 20:45:22 | Re: Proposal: RETURNING primary_key() |