Re: Test failures under Oracle

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

Re: Test failures under Oracle

On Mar 10, 2013, at 12:58 PM, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > On 10 mars 2013, at 10:34, Petite Abeille <petite.abei...@gmail.com> wrote: > >> On Mar 10, 2013, at 9:52 AM, Aymeric Augustin >> <aymeric.augus...@polytechnique.or

Re: Test failures under Oracle

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:

Re: Test failures under Oracle

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

Re: Test failures under Oracle

On Mar 10, 2013, at 7:56 PM, Petite Abeille <petite.abei...@gmail.com> 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

Re: Test failures under Oracle

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

Re: Test failures under 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

Re: Test failures under Oracle

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:

Re: Test failures under Oracle

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

Re: Test failures under Oracle

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

Re: Test failures under Oracle

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

Re: Using EXISTS instead of IN for subqueries

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

Re: The model API and strong typing

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

Re: RFC: "UPSERT" in PostgreSQL

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

Re: RFC: "UPSERT" in PostgreSQL

On Sep 28, 2014, at 11:21 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Sun, Sep 28, 2014 at 1:51 AM, Petite Abeille > <petite.abei...@gmail.com> wrote: >> For diversity's sake, and for the record, I, for one, would definitively >> rather have the standard

Re: RFC: "UPSERT" in PostgreSQL

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

Re: RFC: "UPSERT" in PostgreSQL

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