On Sep 29, 2014, at 2:46 PM, shmengie <1st...@gmail.com> wrote:
> Merge -- bulk loading foreign data -no guaranty
>
> upsert -- insert or update row w/confidence.
Sounds like a difference without a distinction.
Let spin it a different way: the MERGE syntax, and broad semantic, is fine as
it i
On Sep 28, 2014, at 9:15 PM, Peter Geoghegan wrote:
> Would you be happier with that?
I would be happier with a clean MERGE statement implementation in Postgres,
yes. And yes, I have followed Postgres' agonizing debate over the years about
the subject. But I personally think it has been fram
On Sep 28, 2014, at 3:32 PM, Aymeric Augustin
wrote:
> You're allowed to disagree with that decision, however:
You are right. Apologies about that. Moving along.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)
On Sep 28, 2014, at 11:21 AM, Peter Geoghegan wrote:
> On Sun, Sep 28, 2014 at 1:51 AM, Petite Abeille
> wrote:
>> For diversity's sake, and for the record, I, for one, would definitively
>> rather have the standard MERGE statement instead of yet another 'weird
On Sep 28, 2014, at 1:01 AM, Peter Geoghegan wrote:
> The SQL standard's MERGE statement is kind of weird...
For diversity's sake, and for the record, I, for one, would definitively rather
have the standard MERGE statement instead of yet another 'weird' UPSERT
concoction peculiar to Postgres.
On Mar 1, 2014, at 9:14 AM, Martin Matusiak wrote:
> Is there a rationale for why we don't do this?
Perhaps because handling data constraint is the db job?
In the case of sqlite, which is very free form, simply define the proper check
constraints.
For example:
create table foo
(
bar text
On Mar 26, 2013, at 10:03 PM, Alex Gaynor wrote:
> For what it's worth, SQL2011 does define OFFSET, finally.
Perhaps worthwhile mentioning as well :
"Do not try to implement a scrolling window using LIMIT and OFFSET. Doing so
will become sluggish as the user scrolls down toward the bottom of
On Mar 26, 2013, at 4:19 PM, Michael Manfre wrote:
> Maybe someday the non-standard LIMIT/OFFSET keywords will get added to the
> standard (I truly hope this happens) so Oracle, MSSQL, DB2, and Informix
> could share SQL with postgres and mysql without needing to mangle it.
FWIW, Oracle 12c is
On Mar 10, 2013, at 9:36 PM, Ian Kelly wrote:
> These particular lookups have a long history of being tweaked due to
> users coming up with installations where the existing queries did not
> work. See tickets #5985, #11017 and #14149. I'd rather not reopen
> this issue unless the current imple
On Mar 10, 2013, at 9:28 PM, Ian Kelly wrote:
> Digging into the code a bit further, I see that the postgresql backend
> accomplishes this by tacking '::text' onto the end of the field name
> when the lookup is a string-based lookup like startswith. Oracle
> could probably do something similar
On Mar 10, 2013, at 9:12 PM, Florian Apolloner wrote:
> Interesting. Out of curiosity may I ask what brought you to this ML then?
Ah, oh, yes, well… subscribed to the django mailing lists a while back to see
what was all the fuss about :)
That specific thread caught my eye, as I'm familiar w
On Mar 10, 2013, at 8:28 PM, Aymeric Augustin
wrote:
> https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L548-L555
Last but not least… I couldn't help notice these suspicious looking operators:
https://github.com/django/django/blob/master/django/db/backends/oracle
On Mar 10, 2013, at 8:45 PM, Florian Apolloner wrote:
> Patches welcome…
Yes, I wish I knew Python. Sadly I don't. :)
> Well the issue is that nobody wrote get_key_columns yet, so we'd need a
> patch which adds this method to the oracle backend, examples can be taken
> from postgres
> http
On Mar 10, 2013, at 8:28 PM, Aymeric Augustin
wrote:
> Django does this already:
> https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L548-L555
Perfect.
In the case of #20015, the issue is the other way round… the literal '2008%'
cannot be implicitly converted to
On Mar 10, 2013, at 7:56 PM, Petite Abeille wrote:
> If you are not explicit, the session NLS format is applied, with
> unpredictable results.
For the record, one can always set this explicitly at the session level as
well, e.g.:
alter session set nls_date_format = '-MM-DD&q
On Mar 10, 2013, at 7:11 PM, Ian Kelly wrote:
> #20015 looks like an expected failure. Oracle supports lookups of
> date fields using strings by implicitly converting the string to a
> date. The test is doing a startswith lookup that is going to produce
> sql that looks something like "WHERE d
On Mar 10, 2013, at 7:04 PM, Florian Apolloner wrote:
> It's not always just SQL and even then, before formulating them in SQL it's
> easier to just ask the Oracle users to take a look at the failing issues
> and provide help there… Eg: https://code.djangoproject.com/ticket/20014 is
> a perfe
On Mar 10, 2013, at 12:58 PM, Aymeric Augustin
wrote:
> On 10 mars 2013, at 10:34, Petite Abeille wrote:
>
>> On Mar 10, 2013, at 9:52 AM, Aymeric Augustin
>> wrote:
>>
>>> Oracle's online docs are a sad joke
>>
>> Specifically? Th
On Mar 10, 2013, at 9:52 AM, Aymeric Augustin
wrote:
> Oracle's online docs are a sad joke
Specifically? The Oracle document is rather extensive and detailed. What's
confusing you?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To u
19 matches
Mail list logo
