Lincoln Yeoh writes:
However raw control characters can still cause problems in the various
stages from the source to the DB.
I still don't see why. You are merely speculating about implementation
fallacies that aren't there.
--
Peter Eisentraut [EMAIL PROTECTED]
Yes it's speculation. The implementation at the DB isn't there, neither are
the associated DBD/JDBC/ODBC drivers for it.
Basically if the fallacies aren't in postgresql _if_ the decision is to
implement it, I'd be happy.
I was just noting (perhaps superfluously) that backspaces and friends
Lincoln Yeoh writes:
But for the ANSI standard how does one stuff \r\n\t and other control
characters into the database?
If there's no way other than actually sending the control characters then
that is a bad idea especially from a security viewpoint.
Why??
--
Peter Eisentraut [EMAIL
At 09:58 PM 6/4/02 +0200, Peter Eisentraut wrote:
Lincoln Yeoh writes:
But for the ANSI standard how does one stuff \r\n\t and other control
characters into the database?
If there's no way other than actually sending the control characters then
that is a bad idea especially from a
Andrew Pimlott wrote:
On Wed, May 08, 2002 at 06:47:46PM +0200, Zeugswetter Andreas SB SD wrote:
When we are talking about the places where you need double escaping
(once for parser, once for input function) to make it work, I would also
say that that is very cumbersome (not broken,
On Mon, June 03 Bruce wrote:
On Wed, May 08, 2002 at 06:47:46PM +0200, Zeugswetter SB SD Andreas wrote:
When we are talking about the places where you need double escaping
(once for parser, once for input function) to make it work, I would also
say that that is very cumbersome (not
At 01:20 PM 6/3/02 +0200, Zeugswetter Andreas SB SD wrote:
for two things, one for escaping single quotes and for escaping standard
C characters, like \n. While we can use the standard-supported '' to
insert single quotes, what should we do with \n? The problem is
switching to standard
It is my experience that most other free software projects take
standards compliance more seriously than PostgreSQL, and my strong
opinion that both the project and its users (not to mention the
whole SQL database industry, eventually) would benefit from better
support for the SQL standard.
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
* Allow backslash handling in quoted strings to be disabled for portability
BTW, what about embedded NUL characters in text strings? ;-)
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart
Florian Weimer [EMAIL PROTECTED] writes:
BTW, what about embedded NUL characters in text strings? ;-)
There's approximately zero chance of that happening in the foreseeable
future. Since null-terminated strings are the API for both the parser
and all datatype I/O routines, there'd have to be a
I posted this some time ago to pgsql-bugs[1], to no response. So
I'll venture to try here.
Postgres breaks the standard for string literals by supporting
C-like escape sequences. This causes pain for people trying to
write portable applications. Is there any hope for an option to
follow the
Andrew Pimlott wrote:
I posted this some time ago to pgsql-bugs[1], to no response. So
I'll venture to try here.
Postgres breaks the standard for string literals by supporting
C-like escape sequences. This causes pain for people trying to
write portable applications. Is there any hope
On Thu, 25 Apr 2002 10:41:56 EDT, Bruce Momjian wrote:
Andrew Pimlott wrote:
I posted this some time ago to pgsql-bugs[1], to no response. So
I'll venture to try here.
Postgres breaks the standard for string literals by supporting
C-like escape sequences. This causes pain for people
F Harvell [EMAIL PROTECTED] writes:
This also poses the biggest problem in terms of legacy compatibility.
Perhaps the answer is to add a runtime config option (and default it
to ANSI) and possibly deprecate the C escaping.
While I wouldn't necessarily object to a runtime option, I do object
Tom Lane wrote:
F Harvell [EMAIL PROTECTED] writes:
This also poses the biggest problem in terms of legacy compatibility.
Perhaps the answer is to add a runtime config option (and default it
to ANSI) and possibly deprecate the C escaping.
While I wouldn't necessarily object to a runtime
On Thu, 25 Apr 2002 15:07:44 EDT, Tom Lane wrote:
F Harvell [EMAIL PROTECTED] writes:
This also poses the biggest problem in terms of legacy compatibility.
Perhaps the answer is to add a runtime config option (and default it
to ANSI) and possibly deprecate the C escaping.
While I
16 matches
Mail list logo
