t == t...@sss.pgh.pa.us writes:
t> Brandon Metcalf writes:
t> > d == dal...@solfertje.student.utwente.nl writes:
t> > d> On May 26, 2009, at 6:37 PM, Brandon Metcalf wrote:
t> > d> > The issue here is that these reduce back to my original problem.
For
t> > d> > example, if I use a CASE
Brandon Metcalf writes:
> d == dal...@solfertje.student.utwente.nl writes:
> d> On May 26, 2009, at 6:37 PM, Brandon Metcalf wrote:
> d> > The issue here is that these reduce back to my original problem. For
> d> > example, if I use a CASE statement and I fall through to the ELSE,
> d> > then
d == dal...@solfertje.student.utwente.nl writes:
d> On May 26, 2009, at 6:37 PM, Brandon Metcalf wrote:
d> > j> option 2: case when '$length' = '' ...
d> >
d> > j> you can use case like this:
d> >
d> > j>UPDATE foo
d> > j> SET
d> > j>pattern = '$pattern',
d> > j>s
On May 26, 2009, at 6:37 PM, Brandon Metcalf wrote:
j> option 2: case when '$length' = '' ...
j> you can use case like this:
j>UPDATE foo
j> SET
j>pattern = '$pattern',
j>shape = '$shape',
j>length = case when '$length'='' then length else
'$length' end,
j
j == ja...@xnet.co.nz writes:
j> On 2009-05-22, Brandon Metcalf wrote:
j> > Assume I have an UPDATE statement that looks like
j> >
j> > UPDATE foo
j> > SET
j> > pattern = '$pattern',
j> > shape = '$shape',
j> > length = $length,
j> > comment = '$comment'
On 2009-05-22, Brandon Metcalf wrote:
> Assume I have an UPDATE statement that looks like
>
> UPDATE foo
> SET
> pattern = '$pattern',
> shape = '$shape',
> length = $length,
> comment = '$comment'
> WHERE foo_id = $foo_id
>
> and length is defined as NUMERIC.
Brandon Metcalf wrote:
> Assume I have an UPDATE statement that looks like
>
> UPDATE foo
> SET
> pattern = '$pattern',
> shape = '$shape',
> length = $length,
> comment = '$comment'
> WHERE foo_id = $foo_id
>
> and length is defined as NUMERIC. Is there any
Assume I have an UPDATE statement that looks like
UPDATE foo
SET
pattern = '$pattern',
shape = '$shape',
length = $length,
comment = '$comment'
WHERE foo_id = $foo_id
and length is defined as NUMERIC. Is there any kind of magic that
would allow me to use the
On Wed, Apr 30, 2008 at 9:10 AM, Andy Anderson
<[EMAIL PROTECTED]> wrote:
In a test I just did, the sequence \" (backslash double-quote) is
interpreted as just a " inside of the E'...' string constant
expression.
This is great, since PHP's addslashes() sticks them in along with
the other
st
On Wed, Apr 30, 2008 at 7:10 AM, Andy Anderson <[EMAIL PROTECTED]> wrote:
> In a test I just did, the sequence \" (backslash double-quote) is
> interpreted as just a " inside of the E'...' string constant expression.
> This is great, since PHP's addslashes() sticks them in along with the other
> st
Ah, slight ambiguity here. Perhaps this might best say "Any other
character following a backslash is taken literally, and the backslash
is removed."
Thanks,
-- Andy
On Apr 30, 2008, at 10:28 AM, Tom Lane wrote:
Andy Anderson <[EMAIL PROTECTED]> writes:
In a test I just did, the sequence
Andy Anderson wrote:
In a test I just did, the sequence \" (backslash double-quote) is
interpreted as just a " inside of the E'...' string constant expression.
This is great, since PHP's addslashes() sticks them in along with the
other stuff I really need to quote like ' and \. But I see that \
Andy Anderson <[EMAIL PROTECTED]> writes:
> In a test I just did, the sequence \" (backslash double-quote) is
> interpreted as just a " inside of the E'...' string constant
> expression. This is great, since PHP's addslashes() sticks them in
> along with the other stuff I really need to quote
In a test I just did, the sequence \" (backslash double-quote) is
interpreted as just a " inside of the E'...' string constant
expression. This is great, since PHP's addslashes() sticks them in
along with the other stuff I really need to quote like ' and \. But I
see that \" isn't documente
On Wed, 9 Apr 2008 19:11:57 +0200
Alban Hertroys <[EMAIL PROTECTED]> wrote:
> On Apr 9, 2008, at 5:27 PM, Jozef Ševčík wrote:
> > In MSSQL I had something like:
> > SELECT Column1,Column2 from MyTable
> >
> > In PgSQL I write:
> > SELECT “Column1”, “Column2” from “MyTable”
> >
> > Which is fine an
Jozef Ševčík wrote:
So it all depends on how table is exactly created, thank you.
A last question - is there any way how to 'switch' this for
table without re-creating table again ?
ALTER TABLE "MixedCase" RENAME TO "lowercase";
The double quotes are optional on all lower case identifiers.
To: Jozef Ševčík
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Quoting table/column names vs performance
On Apr 9, 2008, at 5:27 PM, Jozef Ševčík wrote:
> In MSSQL I had something like:
> SELECT Column1,Column2 from MyTable
>
> In PgSQL I write:
> SELECT “Column1”, “Column2” from
On Apr 9, 2008, at 5:27 PM, Jozef Ševčík wrote:
In MSSQL I had something like:
SELECT Column1,Column2 from MyTable
In PgSQL I write:
SELECT “Column1”, “Column2” from “MyTable”
Which is fine and working, I have no doubt about it. I’m just
guessing if this does not affect performance
in any wa
/ Best regards,
Jozef Ševčík
[EMAIL PROTECTED]
+420 608 782 813
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 6:57 PM
To: Jozef Ševčík
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Quoting table/column names vs performanc
Jozef Ševčík wrote:
Richard,
thanks for the answer.
In fact, I double-quoted identifiers only because PgSQL forced me to do so
when using capitalized letters in table/column name.
Well, if you don't quote them they get folded to lower-case and you get
case-insensitive matching.
CREATE TABLE
formance penalty for this ?
S pozdravom / Best regards,
Jozef Ševčík
[EMAIL PROTECTED]
+420 608 782 813
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 5:49 PM
To: Jozef Ševčík
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL]
Jozef Ševčík wrote:
Hi all,
I just switched from MS SQL to PostgreSQL on project and have
question about double-quoting names of fields/tables regarding to
performance.
If the cost of quoting column-names is a significant part of your query
costs, you must have some very fast queries. I would
Hi all,
I just switched from MS SQL to PostgreSQL on project and have question about
double-quoting names of fields/tables
regarding to performance.
In MSSQL I had something like:
SELECT Column1,Column2 from MyTable
In PgSQL I write:
SELECT "Column1", "Column2" from "MyTable"
Which is fine and
Uh...
Just kidding, I guess. Wish I had a screen capture of what I had done
before because I swear I was unable to create a table in the user
namespace after having created it. But now that I look more closely
(including when running current_schemas(true)), everything looks fine.
Sorry fo
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> This is an important distinction because testing reveals that the
> quoted $user after the reversal is no longer actually a dynamic
> variable that results in a search_path that resolves to the current
> user.
Really? It works fine for me:
re
The default search_path is $user, public.Say I wanted to reverse this in a database called d:First of all:d=> show search_path; search_path-- $user,public(1 row)Then:d=> alter database d set search_path to public, '$user';Then, in a new session:d=> show search_path; search_path-
Ron Peterson <[EMAIL PROTECTED]> writes:
> So it seems like the single quotes are causing :v_encoding to be read as
> a string literal for ENCODING, but they don't do that for WITH PASSWORD.
Yeah, they behave the same in both cases. If you'd experimented you
would have found that the password was
Ron Peterson wrote:
> Single quotes appear to behave
> differently in diffent contexts.
>
> CREATE USER
> :v_dbadmin
> WITH PASSWORD
> ':v_dbpass';
This sets your password to ":v_dbpass", which is probably not what you
wanted. Your next message contains the correct solution: include the
quo
On Sat, Feb 19, 2005 at 05:30:25PM -0500, Ron Peterson wrote:
> Hi,
>
> I'm trying to use PostgreSQL's internal variables to simplify some shell
> scripting database setup stuff. Single quotes appear to behave
> differently in diffent contexts.
I decided to just do the proper quoting within the
Hi,
I'm trying to use PostgreSQL's internal variables to simplify some shell
scripting database setup stuff. Single quotes appear to behave
differently in diffent contexts.
CREATE USER
:v_dbadmin
WITH PASSWORD
':v_dbpass';
CREATE USER
CREATE USER worked o.k.
CREATE DATABASE
:v_dbna
Date: Thu, 24 Jul 2003 11:09:41 -0400
From: Tom Lane <[EMAIL PROTECTED]>
(a) So that numerics don't get quoted. (b) The original coding was
wrong, since its rule for deciding when to quote had nothing to do
with the contents of the string being quoted, and it could thus fail
to
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
> my question is: why this make-work change?
(a) So that numerics don't get quoted. (b) The original coding was
wrong, since its rule for deciding when to quote had nothing to do with
the contents of the string being quoted, and it could thus fail to q
greetings,
previously (7.1.x), an array of text would be returned:
{"d","e","f"}
but w/ 7.3.3 i see:
{d,e,f}
there is mention of this in section 5.12 "Arrays" of the manual,
including the unfriendly consequence: callers must be able to handle
either case. my question is: why t
If that doesn't work, I would like to know, to avoid any hidden gotchas. I
suppose it is considered uncommon to need this since most search techniques
do not include punctuation. However, if one were to make extensive use of
regex searches, this issue could occur often and engender much hair pulli
Open Source for a better Internet"
> From: Lincoln Yeoh <[EMAIL PROTECTED]>
> Date: Fri, 28 Sep 2001 00:40:50 +0800
> To: [EMAIL PROTECTED]
> Subject: [GENERAL] Quoting '?' placeholder in Perl's DBD::Pg?
>
> Hi anyone know how I can quote or turn o
On Tue, 18 Jul 2000, Peter Eisentraut wrote:
> Denis Perchine writes:
>
> > Just a small question: why there is not any quoting routine in libpq.
>
> Can you give an example of what it should do?
Just as a guess, something that parses a string and escapes single quotes,
backslashes and stuff l
Denis Perchine writes:
> Just a small question: why there is not any quoting routine in libpq.
Can you give an example of what it should do?
--
Peter Eisentraut Sernanders väg 10:115
[EMAIL PROTECTED] 75262 Uppsala
http://yi.org/peter-e/Sweden
Hello,
Just a small question: why there is not any quoting routine in libpq.
This is very handy to have one. And also it is quite hard always
write quoting routing for database if you want to have cross database code.
--
Sincerely Yours,
Denis Perchine
--
E-Mail
Bill Sneed wrote:
> I'd like to be able to find a book title that contain C++ in the
> title
>
> select * from books where title ~* 'C++' doesn't work.
>
> I've tried all the basic methods of quoting the Plus (+) signs but
> none seem to work...
>
> Any hints would be most appreciated
>
I'd like to be able to find a book title that contain C++ in the
title
select * from books where title ~* 'C++' doesn't work.
I've tried all the basic methods of quoting the Plus (+) signs but
none seem to work...
Any hints would be most appreciated
Thanks...
Bill Sneed, Pro
40 matches
Mail list logo
