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
(n
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]
-
OK, I was wrong. '' can be sufficient. The DB just has to treat everything
between single quotes as data except for '' which is treated as a ' in the
data.
However raw control characters can still cause problems in the various
stages from the source to the DB.
Cheerio,
Link.
Lincoln Yeoh wro
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
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 [EMA
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 st
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 cumber
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
> 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 standa
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
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 http
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.
>
> Whil
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
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 obje
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
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 h
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 st
17 matches
Mail list logo
