Comments with embedded single quotes

/* log will probably just be a table for Saruman's use only. */

Are single quotation marks not allowed in comments?

test2=# /* John's cat is fat. */
test2'#
test2'# '*/
test2-# ;
ERROR: Unterminated quoted string
test2=#

I have the SQL + comments for creating my database in files that are just
imported in psql.

Yikes, bug alert. I will take a look at it, if Peter doesn't beat me to
it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Richard Harvey Chapman <hchapman@3gfp.com> writes:

Are single quotation marks not allowed in comments?

test2=# /* John's cat is fat. */
test2'#
test2'# '*/
test2-# ;
ERROR: Unterminated quoted string
test2=#

They are, but it looks like psql's primitive parser is confused here.
What the backend sees when this is sent is
/* comment */

'*/

and it quite properly complains that the string starting '*/ is not
terminated. But it looks like psql mistakenly thinks that ' nests
inside /* ... */:

regression=# /*aaa
regression*# 'sss
regression'# ddd
regression'# */
regression'# 'sss
regression*# */
regression-#

Notice the pattern of the 'state' markers in the prompts. It seems
to get the reverse case correct though:

regression-# 'foo
regression'# /*bar
regression'# '
regression-#

Over to you, Peter...

regards, tom lane

Richard Harvey Chapman <hchapman@3gfp.com> writes:

Are single quotation marks not allowed in comments?

test2=# /* John's cat is fat. */
test2'#
test2'# '*/
test2-# ;
ERROR: Unterminated quoted string
test2=#

They are, but it looks like psql's primitive parser is confused here.
What the backend sees when this is sent is
/* comment */

'*/

and it quite properly complains that the string starting '*/ is not
terminated. But it looks like psql mistakenly thinks that ' nests
inside /* ... */:

regression=# /*aaa
regression*# 'sss
regression'# ddd
regression'# */
regression'# 'sss
regression*# */
regression-#

Notice the pattern of the 'state' markers in the prompts. It seems
to get the reverse case correct though:

regression-# 'foo
regression'# /*bar
regression'# '
regression-#

Over to you, Peter...

OK, here is the patch. The problem was that quotes were being checked
before checking if we were in a comment. Patch applied to current tree
only.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

OK, here is the patch. The problem was that quotes were being checked
before checking if we were in a comment. Patch applied to current tree
only.

Nope, now we have the inverse problem. Try

SELECT 'aa--bb';

The timestamp test is now failing because of this.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

[ Charset ISO-8859-1 unsupported, converting... ]

Bruce Momjian writes:

OK, here is the patch. The problem was that quotes were being checked
before checking if we were in a comment. Patch applied to current tree
only.

Nope, now we have the inverse problem. Try

SELECT 'aa--bb';

The timestamp test is now failing because of this.

OK, new patch. I also renamed xcomment to in_xcomment. The important
point, now commented, is that we have to test if we are in quote or an
xcomment before testing for the start of quotes or xcomments.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

OK, I feel silly having to ask this, but I'm paranoid enough that I will
anyway.

The company I work for is about to plop down a very large amount of money
on bigger, better machines to handle the work. We're currently planning on
an 8-way machine running postgres for the database work, and a group
of dual CPU web servers running the CGI applications.

Before we get up to our necks in hardware purchases, I'd like to have
some peace of mind that the performance isn't going to decrease horribly
because of the bandwidth limitations in the ethernet connections.

To describe the setup, the database server will be connected via a
gigabit fiber cable to a switch, with 100-megabit connections to each of the
application servers. So, until we get a larger number of app servers, the
limiting factor will be the 100 megabit connections to each individual
server.

I'd like to feel sure that transmitting the result sets over the ethernet
isn't going to cause a significant decrease in response time. After working
through the numbers, I don't think that it will - but I'd love to hear from
those who have done similar setups.

We enabled some logging in the database library that we use, and here is
some information on our result sets:

average result set size: 1.4 kilobytes
maximum result set size: 633 kilobytes

Of those results, here's a breakdown:

Size Frequency
-------------------
0-8K 96%
8K-17K 2%
17K - 24K 0.02%

and it goes down from there.

So, it seems that it would take a very large number of transactions per
second to saturate either the 100 mbit link to the servers, or the gigabit
pipe to the server.

Am I correct, or should I reevaluate? Any comments are welcome.

steve

Since most RAID servers can't even flood a 100 mbit connection, you're more
than safe with that much bandwidth if most of your traffic is going to be
database related. You might want to factor in all the other network
traffic that will be going over those lines though. For instance, if the
app servers are going to be mounting partitions off of a RAID server on the
same network, and your Internet connection comes in there too, you might
start to run into problems. The database shouldn't even come close though.

At 06:49 PM 6/30/00, you wrote:

Since most RAID servers can't even flood a 100 mbit connection, you're

more

than safe with that much bandwidth if most of your traffic is going to be
database related. You might want to factor in all the other network
traffic that will be going over those lines though. For instance, if the
app servers are going to be mounting partitions off of a RAID server on

the

same network, and your Internet connection comes in there too, you might
start to run into problems. The database shouldn't even come close

though.

Thank you, I appreciate the comments. Each app server is actually going
to have two 100 mbit cards, one to connect it to the RAID array, and one to
connect it to the database machine. Your comments give me even more hope
that this will work as well as we hope. ; )

After this is all set up, if anyone would like, I may type up an
explanation of how things were done as well as costs, for those going
through the same sort of growing pains. It's certainly been a lot of work
for us to hammer out all of the details, hopefully that would help someone
else avoid the work.

steve

After this is all set up, if anyone would like, I may type up an
explanation of how things were done as well as costs, for those going
through the same sort of growing pains. It's certainly been a lot of
work for us to hammer out all of the details, hopefully that would
help someone else avoid the work.

That would be great. It would be fun to see some performance numbers
too. And it would be a great contribution to the "user cases" that help
people see the range of applications and runtime environments which have
been successful.

- Thomas

"Steve Wolfe" <steve@iboats.com> writes:

After this is all set up, if anyone would like, I may type up an
explanation of how things were done as well as costs, for those going
through the same sort of growing pains. It's certainly been a lot of work
for us to hammer out all of the details, hopefully that would help someone
else avoid the work.

Please do --- I think a lot of people would find it interesting.

regards, tom lane