On 3/18/19 5:18 AM, Morris de Oryx wrote:
Sounds like I may have touched a nerve with some. If so, no offense
intended!
There are cases where case-sensitivity is required or desirable, it
would be silly to argue otherwise. Where you have such cases, then
case-sensitive queries are great. Som
Chris Travers schrieb am 18.03.2019 um 13:16:
> MySQL also ignores the standard and does not fold cases.
Unless you configure it to fold to lowercase.
Which in turn is a cure for the fact, that case-sensitivity of table names
depends on the case-sensitivity of the underlying file system (not th
On Sat, Mar 16, 2019 at 3:15 PM Tom Lane wrote:
> Steve Haresnape writes:
> > As I said, I don't want to quote my identifiers. I know what that does. I
> > want to specify them in a certain way, see them in that same way, but
> refer
> > to them in any old way.
> > You can call it normalize or f
On Thu, Mar 14, 2019 at 11:07 PM Steve Haresnape <
s.haresn...@creativeintegrity.co.nz> wrote:
> I'm porting a sql server database to postgresql 9.6. My camelCase
> identifiers are having their humps removed. This is disconcerting and sad.
>
> Is there a cure for this?
>
Double quote them.
>
> I
...hit send by accident
..or BLACK SHOULDERED KITE
You'll see all three regularly, depending on context and writer. It's
always the same bird. A natural search turns up all matches, regardless of
capitalization differences. The hyphens are hardI'm a huge, huge, huge
fan of fuzzy string matchi
Sounds like I may have touched a nerve with some. If so, no offense
intended!
There are cases where case-sensitivity is required or desirable, it would
be silly to argue otherwise. Where you have such cases, then case-sensitive
queries are great. Some RDBMS systems default to case-sensitive search
On 2019-03-16 14:00:34 -0600, Rob Sargent wrote:
> What sort of content is in your field of type text? Certainly, in
> English
> prose, “rob” is different than “Rob”
>
>
> I disagree. While the grammar for written English has rules when to
> write "rob" and when t
> "Morris" == Morris de Oryx writes:
Morris> UUIDs as a type are an interesting case in Postgres. They're
Morris> stored as a large numeric for efficiency (good!), but are
Morris> presented by default in the 36-byte format with the dashes.
Morris> However, you can also search using the da
>> What sort of content is in your field of type text? Certainly, in English
>> prose, “rob” is different than “Rob”
>
> I disagree. While the grammar for written English has rules when to
> write "rob" and when to write "Rob", that distinction usually carries no
> semantic difference. Consider
On 2019-03-15 17:09:49 -0600, Rob Sargent wrote:
> On Mar 15, 2019, at 4:43 PM, Morris de Oryx
> wrote:
>
> The original question has already been answered really well, but it
> reminds
> me to mention that Postgres text/varchar values are case-sensitive. Here's
> a list of the
Steve Haresnape writes:
> As I said, I don't want to quote my identifiers. I know what that does. I
> want to specify them in a certain way, see them in that same way, but refer
> to them in any old way.
> You can call it normalize or fold or whatever. It's a bad design choice,
> and not even a co
On 3/16/19 1:53 AM, Steve Haresnape wrote:
My apologies I sent this reply to David only by mistake.
-- Forwarded message -
From: *Steve Haresnape* <mailto:s.haresn...@creativeintegrity.co.nz>>
Date: Fri, 15 Mar 2019 at 13:09
Subject: Re: Camel case identifiers and f
My apologies I sent this reply to David only by mistake.
-- Forwarded message -
From: Steve Haresnape
Date: Fri, 15 Mar 2019 at 13:09
Subject: Re: Camel case identifiers and folding
To: David G. Johnston
As I said, I don't want to quote my identifiers. I know what that do
We definitely *store* data case-sensitively, we just never want to *search*
on it case-sensitively. That's what citext gives us. Many databases
perform this way as a default. Postgres does not, but it offers
alternatives. The OP is coming from MySQL which, if I remember correctly,
treated non-bina
> On Mar 15, 2019, at 4:43 PM, Morris de Oryx wrote:
>
> The original question has already been answered really well, but it reminds
> me to mention that Postgres text/varchar values are case-sensitive. Here's a
> list of the times when I would like a case-sensitive text field:
>
>Never
The original question has already been answered really well, but it reminds
me to mention that *Postgres text/varchar values are case-sensitive*.
Here's a list of the times when I would like a case-sensitive text field:
Never
Now here's the list of times I would like a case-blind text field:
Steve Haresnape schreef op vr 15-03-2019 om 12:06 [+1300]:
> I'm porting a sql server database to postgresql 9.6. My camelCase
> identifiers are having their humps removed. This is disconcerting and
> sad.
the SQL ISO defines exactly this behaviour (as you note),
so this is be expected
suggestion
Steve Haresnape schrieb am 15.03.2019 um 00:06:
> I'm porting a sql server database to postgresql 9.6. My camelCase
> identifiers are having their humps removed. This is disconcerting and
> sad.
>
> Is there a cure for this?
>
> I don't want to quote my identifiers unless I have to.
You don't ne
On Thu, Mar 14, 2019 at 4:07 PM Steve Haresnape
wrote:
>
> I'm porting a sql server database to postgresql 9.6. My camelCase identifiers
> are having their humps removed. This is disconcerting and sad.
>
> Is there a cure for this?
No
>I don't want to quote my identifiers unless I have to.
Pos
I'm porting a sql server database to postgresql 9.6. My camelCase
identifiers are having their humps removed. This is disconcerting and sad.
Is there a cure for this?
I don't want to quote my identifiers unless I have to. I don't want to use
underscores. Everywhere else I write code I use camel c
20 matches
Mail list logo
