Thread: escape string type for upcoming 8.1
From what I've read, it looks like 8.1 will introduce the E'' escape
string, and eventually postgresql will change the normal '' strings to
be more SQL-compliant.
If I wanted to start being forwards-compatible right now, and I have
existing databases in 7.4 and 8.0, my idea was to create a type E. Any
string using that type would work in 7.4/8.0 as normal, and then when I
upgrade to 8.1 I will drop the type and the applications will still work.
To do that is relatively simple, I'd just use the textin/out functions
that already exist to create the type (which in 7.4/8.0 will give the
desired behavior of escaping). Like so:
CREATE FUNCTION ein(CSTRING) RETURNS E AS 'textin' LANGUAGE internal;
CREATE FUNCTION eout(E) RETURNS CSTRING AS 'textout' LANGUAGE internal;
CREATE TYPE E (input=ein,output=eout);
CREATE CAST (E AS TEXT) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (TEXT AS E) WITHOUT FUNCTION AS IMPLICIT;
Then, when I upgrade a system to 8.1, I can just remove the type, and
all the applications will still work. Eventually when the '' strings are
changed, I can start using those again, but in a SQL-compliant way.
Does this migration path make sense? Will creating the type possibly
cause casting problems of some kind? I read something about possibly
"backpatching" the E'' string to 8.0. If someone did that, what would be
the difference between applying a backpatch and what I did above?
One thing that has me concerned about the idea is that there are some
string constants, like B'' and X'' that aren't really types. Does that
mean that E'' won't be a type? Why are B'' and X'' not types, and are
there any other notations like that that are not types?
Regards,
Jeff Davis
E'' is more a marker than a type. I realize making E a type might work, but it seems unusual. What we could do is backpatch E'' to 8.0.X as a no-op like it will be in 8.1. --------------------------------------------------------------------------- Jeff Davis wrote: > >From what I've read, it looks like 8.1 will introduce the E'' escape > string, and eventually postgresql will change the normal '' strings to > be more SQL-compliant. > > If I wanted to start being forwards-compatible right now, and I have > existing databases in 7.4 and 8.0, my idea was to create a type E. Any > string using that type would work in 7.4/8.0 as normal, and then when I > upgrade to 8.1 I will drop the type and the applications will still work. > > To do that is relatively simple, I'd just use the textin/out functions > that already exist to create the type (which in 7.4/8.0 will give the > desired behavior of escaping). Like so: > > CREATE FUNCTION ein(CSTRING) RETURNS E AS 'textin' LANGUAGE internal; > > CREATE FUNCTION eout(E) RETURNS CSTRING AS 'textout' LANGUAGE internal; > > CREATE TYPE E (input=ein,output=eout); > > CREATE CAST (E AS TEXT) WITHOUT FUNCTION AS IMPLICIT; > > CREATE CAST (TEXT AS E) WITHOUT FUNCTION AS IMPLICIT; > > Then, when I upgrade a system to 8.1, I can just remove the type, and > all the applications will still work. Eventually when the '' strings are > changed, I can start using those again, but in a SQL-compliant way. > > Does this migration path make sense? Will creating the type possibly > cause casting problems of some kind? I read something about possibly > "backpatching" the E'' string to 8.0. If someone did that, what would be > the difference between applying a backpatch and what I did above? > > One thing that has me concerned about the idea is that there are some > string constants, like B'' and X'' that aren't really types. Does that > mean that E'' won't be a type? Why are B'' and X'' not types, and are > there any other notations like that that are not types? > > Regards, > Jeff Davis > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > E'' is more a marker than a type. I realize making E a type might work, > but it seems unusual. > > What we could do is backpatch E'' to 8.0.X as a no-op like it will be in > 8.1. What happens if someone already has a type called "e" ? -- greg
Greg Stark wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > E'' is more a marker than a type. I realize making E a type might work, > > but it seems unusual. > > > > What we could do is backpatch E'' to 8.0.X as a no-op like it will be in > > 8.1. > > What happens if someone already has a type called "e" ? That would be the same problem as someone having a type 'b' or 'x'. It would still work, but not for casts like text'str'. Those letters are caught in the lexer before getting into to the parser. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > > What happens if someone already has a type called "e" ? > > That would be the same problem as someone having a type 'b' or 'x'. It > would still work, but not for casts like text'str'. Those letters are > caught in the lexer before getting into to the parser. What I'm asking about is, are there going to be user applications that were working fine in previous versions but suddenly start breaking when this change is made? Does that affect your decision in whether to backport this to 8.0.x? -- greg
Greg Stark wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > What happens if someone already has a type called "e" ? > > > > That would be the same problem as someone having a type 'b' or 'x'. It > > would still work, but not for casts like text'str'. Those letters are > > caught in the lexer before getting into to the parser. > > What I'm asking about is, are there going to be user applications that were > working fine in previous versions but suddenly start breaking when this change > is made? Does that affect your decision in whether to backport this to 8.0.x? The use of "E" as a data type that is used as E'' seems pretty rare, but I suppose it is possible. We really haven't even discussed the idea of backporting anything, it is just an open issue at the time we release an 8.0.X. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Greg Stark <gsstark@mit.edu> writes:
> What I'm asking about is, are there going to be user applications that were
> working fine in previous versions but suddenly start breaking when this change
> is made? Does that affect your decision in whether to backport this to 8.0.x?
It's worth noting that the E'...' syntax does not fire if there's any
whitespace between the E and the '. If by some chance there are
actually people out there using a type "e" with this syntax, they are
only in trouble if they wrote it with no space, and they can fix it by
adding a space. So I'm not very concerned.
Having said that, though, I'm agin back-porting this. We don't
back-patch feature additions, and this can hardly be described as
a bug fix.
regards, tom lane
Tom Lane wrote:
> Having said that, though, I'm agin back-porting this. We don't
> back-patch feature additions, and this can hardly be described as
> a bug fix.
>
I'm not for or against back porting this feature. I basically want to
know if my plan (appended to this email) was a sane way to write
forward-compatible code.
I can't rely on PQescapeString, because the client library may be a
different version than the server. Right?
The only other logical option is to make a wrapper function around two
string-escaping functions that checks the server version and creates a
string accordingly.
Regards,
Jeff Davis
PS: my plan for making an E'' like string in 8.0:
CREATE FUNCTION ein(CSTRING) RETURNS E AS 'textin' LANGUAGE internal;
CREATE FUNCTION eout(E) RETURNS CSTRING AS 'textout' LANGUAGE internal;
CREATE TYPE E (input=ein,output=eout);
CREATE CAST (E AS TEXT) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (TEXT AS E) WITHOUT FUNCTION AS IMPLICIT;
Bruce Momjian wrote:
> E'' is more a marker than a type. I realize making E a type might work,
> but it seems unusual.
>
> What we could do is backpatch E'' to 8.0.X as a no-op like it will be in
> 8.1.
>
Bruce,
Is it possible in the 8.1 betas to 'switch on' on the standard SQL
escape behavior? This is from the use-case perspective of someone who
does not have backwards compatibility concerns, rather, I'd like to
preemptively forward-port / certify an app from another databases, onto
PostgreSQL -- so all I need to do is switch that config on, if possible.
From the changelog:
"While this release does not change the <default?> handling of
backslashes in strings, it does add new configuration parameters to help
users migrate applications for future releases:
o standard_conforming_strings ......
o escape_string_warning ......
The standard_conforming_strings value is read-only. ...."
The last quoted sentence seems to answer my question (as no), but
hopeful optimism is my motto :-)
If it is indeed readonly, can it be made 'writable' before the 8.3
release where is would be made the default behavior? For that matter, if
the current backslash behavior stayed as the default for pre-8.3
releases, and the patches are backported, I don't see any harm to the
old-style apps/users; yet the correct behavior option is a useful
"opt-in" one (one that I would like to try, now, even on 8.1).
Thank you,
-Ken
Ken Johanson wrote: > Bruce Momjian wrote: > > E'' is more a marker than a type. I realize making E a type might work, > > but it seems unusual. > > > > What we could do is backpatch E'' to 8.0.X as a no-op like it will be in > > 8.1. > > > > Bruce, > > Is it possible in the 8.1 betas to 'switch on' on the standard SQL > escape behavior? This is from the use-case perspective of someone who > does not have backwards compatibility concerns, rather, I'd like to > preemptively forward-port / certify an app from another databases, onto > PostgreSQL -- so all I need to do is switch that config on, if possible. > > From the changelog: > > "While this release does not change the <default?> handling of > backslashes in strings, it does add new configuration parameters to help > users migrate applications for future releases: > > o standard_conforming_strings ...... > > o escape_string_warning ...... > > The standard_conforming_strings value is read-only. ...." > > The last quoted sentence seems to answer my question (as no), but > hopeful optimism is my motto :-) > > If it is indeed readonly, can it be made 'writable' before the 8.3 > release where is would be made the default behavior? For that matter, if > the current backslash behavior stayed as the default for pre-8.3 > releases, and the patches are backported, I don't see any harm to the > old-style apps/users; yet the correct behavior option is a useful > "opt-in" one (one that I would like to try, now, even on 8.1). The configuration parameter will be writable in 8.2. We would have liked to have it writable in 8.1 but found it too complex to do in a limited amount of time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073