On Sat, Sep 27, 2014 at 3:13 PM, Ramiro Morales wrote:
> > I wonder if this also has implications for checking whether a given
> > locale is present on the system. It looks to me like we also do this
> > case-sensitively right now, but we should do it case-insensitively. This
> > might be a bit o
Hi Wayne,
On Mon, Sep 29, 2014 at 5:27 AM, Wayne Ye wrote:
>
> Per official I18n wiki:
> https://docs.djangoproject.com/en/1.4/topics/i18n/translation/#using-translations-outside-views-and-templates
>
> I was using *translation.get_language()* method to retrieve the client
> preferred language:
>
Hi Ramiro,
Thank you very much for replying the thread, I read your testing code, it
makes totally sense, however I guess there might be still some issues, I am
not expert here but let me explain more details about what I found:
Per official I18n wiki:
https://docs.djangoproject.com/en/1.4/topi
On Sun, Sep 28, 2014 at 12:44 PM, Petite Abeille
wrote:
> 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 framed in the wrong light
> si
On Sep 28, 2014, at 12:44 PM, Petite Abeille wrote:
> Postgres has convince itself that it somehow cannot support MERGE. Therefore
> it will not.
There's no question that PostgreSQL could support SQL MERGE. But SQL MERGE is
not what people are asking for when they ask for UPSERT. PostgreS
Ok, I'll do it tomorrow.
On Sunday, September 28, 2014 5:35:31 PM UTC+2, Florian Apolloner wrote:
>
> Hi Marcin,
>
> can you please open a ticket for this? If you are up to it, a patch with
> tests would be superb!
>
> Thanks,
> Florian
>
> On Sunday, September 28, 2014 1:26:42 PM UTC+2, Marcin N
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 28 September 2014 19:30, Aymeric Augustin
wrote:
> "Obviously the PostgreSQL project can make its own choices. But I'm surprised
> that you're proposing non-standard syntax and semantics, considering
> PostgreSQL's tradition to comply with SQL standards. Even if you disagree with
> some aspect
On Sun, Sep 28, 2014 at 4:44 AM, Petite Abeille
wrote:
> Again, your house, your choice. But it seems a bit self-indulgent to concoct
> your very own take on MERGE, with baroque syntax, peculiar semantic, and all,
> just because some abstract aspects of the MERGE specification is not to you
> l
On 28 sept. 2014, at 19:57, Simon Riggs wrote:
>> 1) The django-developers mailing list isn't the place to rehash the debate,
>> 2) The disparaging vocabulary you're using isn't acceptable in this forum,
>> 3) Personal attacks based on prejudice will not be tolerated.
>
> Well, for 1) any commen
On 28 September 2014 14:32, Aymeric Augustin
wrote:
> On 28 sept. 2014, at 13:44, Petite Abeille wrote:
>
>> Again, your house, your choice. But it seems a bit self-indulgent to concoct
>> your very own take on MERGE, with baroque syntax, peculiar semantic, and
>> all, just because some abstrac
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)
Hi Marcin,
can you please open a ticket for this? If you are up to it, a patch with
tests would be superb!
Thanks,
Florian
On Sunday, September 28, 2014 1:26:42 PM UTC+2, Marcin Nowak wrote:
>
> Hello,
>
> After sereral minutes while using new Django (1.7) in DEBUG mode, I've got
> enigmatic e
On Sunday 28 September 2014 09:33:06 Simon Riggs wrote:
> On 28 September 2014 02:22, Shai Berger wrote:
> > Upon reading the docs, I was a little surprised to see that in terms of
> > triggers etc, the operation is always considered an INSERT. I would
> > expect it to be considered an insert for
On 28 sept. 2014, at 13:44, Petite Abeille wrote:
> Again, your house, your choice. But it seems a bit self-indulgent to concoct
> your very own take on MERGE, with baroque syntax, peculiar semantic, and all,
> just because some abstract aspects of the MERGE specification is not to you
> likin
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'
>> UPSERT concoction peculiar
Hello,
After sereral minutes while using new Django (1.7) in DEBUG mode, I've got
enigmatic error on the screen: "A server error occurred. Please contact the
administrator."
This message is shown when another exception is raised within
django.core.handlers.base.handle_uncaught_exception.
What e
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'
> UPSERT concoction peculiar to Postgres.
A few people have said that, but then when you lo
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.
There will be some postgresql specific features in Django 1.8 (at least
array fields, probably also hstore, ranges and jsonb). There are also a
couple of new features which have already landed which leverage postgresql
specific features when present and fall back otherwise (uuid, interval).
I am i
20 matches
Mail list logo
