pgsql: Fix up text concatenation so that it accepts all the reasonable
Log Message:
-----------
Fix up text concatenation so that it accepts all the reasonable cases that
were accepted by prior Postgres releases. This takes care of the loose end
left by the preceding patch to downgrade implicit casts-to-text. To avoid
breaking desirable behavior for array concatenation, introduce a new
polymorphic pseudo-type "anynonarray" --- the added concatenation operators
are actually text || anynonarray and anynonarray || text.
Modified Files:
--------------
pgsql/doc/src/sgml:
datatype.sgml (r1.203 -> r1.204)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/datatype.sgml.diff?r1=1.203&r2=1.204)
extend.sgml (r1.34 -> r1.35)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/extend.sgml.diff?r1=1.34&r2=1.35)
func.sgml (r1.381 -> r1.382)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml.diff?r1=1.381&r2=1.382)
plpgsql.sgml (r1.109 -> r1.110)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/plpgsql.sgml.diff?r1=1.109&r2=1.110)
xfunc.sgml (r1.127 -> r1.128)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/xfunc.sgml.diff?r1=1.127&r2=1.128)
pgsql/src/backend/catalog:
pg_proc.c (r1.144 -> r1.145)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/pg_proc.c.diff?r1=1.144&r2=1.145)
pgsql/src/backend/executor:
functions.c (r1.116 -> r1.117)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/functions.c.diff?r1=1.116&r2=1.117)
pgsql/src/backend/parser:
parse_agg.c (r1.77 -> r1.78)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_agg.c.diff?r1=1.77&r2=1.78)
parse_coerce.c (r2.154 -> r2.155)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_coerce.c.diff?r1=2.154&r2=2.155)
parse_func.c (r1.196 -> r1.197)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_func.c.diff?r1=1.196&r2=1.197)
pgsql/src/backend/utils/adt:
pseudotypes.c (r1.19 -> r1.20)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/pseudotypes.c.diff?r1=1.19&r2=1.20)
xml.c (r1.43 -> r1.44)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/xml.c.diff?r1=1.43&r2=1.44)
pgsql/src/backend/utils/fmgr:
funcapi.c (r1.34 -> r1.35)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/fmgr/funcapi.c.diff?r1=1.34&r2=1.35)
pgsql/src/include/catalog:
catversion.h (r1.410 -> r1.411)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h.diff?r1=1.410&r2=1.411)
pg_operator.h (r1.152 -> r1.153)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_operator.h.diff?r1=1.152&r2=1.153)
pg_proc.h (r1.458 -> r1.459)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h.diff?r1=1.458&r2=1.459)
pg_type.h (r1.184 -> r1.185)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_type.h.diff?r1=1.184&r2=1.185)
pgsql/src/include/utils:
builtins.h (r1.295 -> r1.296)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/builtins.h.diff?r1=1.295&r2=1.296)
lsyscache.h (r1.118 -> r1.119)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/lsyscache.h.diff?r1=1.118&r2=1.119)
pgsql/src/pl/plpgsql/src:
pl_comp.c (r1.114 -> r1.115)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_comp.c.diff?r1=1.114&r2=1.115)
pgsql/src/test/regress/expected:
text.out (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/text.out.diff?r1=1.3&r2=1.4)
pgsql/src/test/regress/sql:
text.sql (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/text.sql.diff?r1=1.3&r2=1.4)
"Tom Lane" <tgl@postgresql.org> writes:
Log Message:
-----------
Fix up text concatenation so that it accepts all the reasonable cases that
were accepted by prior Postgres releases. This takes care of the loose end
left by the preceding patch to downgrade implicit casts-to-text. To avoid
breaking desirable behavior for array concatenation, introduce a new
polymorphic pseudo-type "anynonarray" --- the added concatenation operators
are actually text || anynonarray and anynonarray || text.
Just a crazy thought -- probably not worth doing now or perhaps ever -- but I
thought I would get it down in bits:
The above change eliminated cast functions to and from text by using the text
i/o functions. We could do the same for casts to and from bytea using binary
i/o functions.
I'm not sure how important it is for users to be able to reliably store any
data type in a bytea -- certainly not as important as being able to reliably
cast to and from text.
Perhaps if you're doing some form of replication between different
architectures you might want to use binary representation for your transfers.
Or if you're doing something in a PL language like compressing or bundling up
multiple data in a container format or something.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Hi,
Gregory Stark wrote:
Perhaps if you're doing some form of replication between different
architectures you might want to use binary representation for your transfers.
Or if you're doing something in a PL language like compressing or bundling up
multiple data in a container format or something.
I'm not quite sure I understand where you're coming from, but isn't that
what the send and recv functions for most data types are for? Don't
those provide a cross-platform compatible binary representation?
Regards
Markus
Markus Schiltknecht <markus@bluegap.ch> writes:
Gregory Stark wrote:
Perhaps if you're doing some form of replication between different
architectures you might want to use binary representation for your transfers.
Or if you're doing something in a PL language like compressing or bundling up
multiple data in a container format or something.
I'm not quite sure I understand where you're coming from, but isn't that
what the send and recv functions for most data types are for? Don't
those provide a cross-platform compatible binary representation?
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible. There might be some excuse for
doing this within a single architecture, but I can't get very excited
about it ...
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible. There might be some excuse for
doing this within a single architecture, but I can't get very excited
about it ...
Well they're not very useful for their intended purpose of client-server
communication if they're not.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Hello Tom,
Tom Lane wrote:
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible.
Can you elaborate on this? AFAICT the send/recv functions use network
byte ordering. What are the other problems between different architectures?
There might be some excuse for
doing this within a single architecture, but I can't get very excited
about it ...
Is the textual representation (i.e. OidOutputFunctionCall) more cross
platform compatible?
Gregory Stark wrote:
Well they're not very useful for their intended purpose of
client-server communication if they're not.
Agreed. Up until now, I'd have considered it a bug, if a send/recv on
different platforms would not lead to the very same result.
Regards
Markus
Markus Schiltknecht <markus@bluegap.ch> writes:
Tom Lane wrote:
I think you'd be nuts to bet your data on the binary representations
really being cross-platform compatible.
Can you elaborate on this? AFAICT the send/recv functions use network
byte ordering. What are the other problems between different architectures?
Well, you're probably fine with integers and text, but beyond that it
gets a bit more dicey. I wouldn't want to assume that floats are
compatible across any random pair of architectures, and in the more
complex datatypes (such as arrays or geometric types) there might be
some impact from alignment rules. (Or not, I'm too lazy to go look at
the moment.)
In any one situation you can doubtless find out by testing whether
you've got a problem. I'm just nervous about a blithe suggestion that
someone could build a cross-platform backup solution this way. That
sounds like a recipe for getting burnt and not finding out till it's
too late to fix it.
regards, tom lane
Hi,
Tom Lane wrote:
Well, you're probably fine with integers and text, but beyond that it
gets a bit more dicey. I wouldn't want to assume that floats are
compatible across any random pair of architectures, and in the more
complex datatypes (such as arrays or geometric types) there might be
some impact from alignment rules. (Or not, I'm too lazy to go look at
the moment.)
Okay, thank you for the hints, I'll go figure out.
Regards
Markus