Tom Lane escreveu:
> I'm not inclined to go and retroactively document that these spellings
> are possible but deprecated in the old branches. I think that would
> just confuse matters even more.
>
Is it worth preventing that sloppy implementation in the old branches?
--
Euler Taveira de Oli
Dear Tom,
The REFERENTIAL_CONSTRAINTS table in the information_schema references a
constaint through its database/schema/name, but this information is not
unique, so it may identify several constraints, thus the information
derived may not be consistent.
Postgres does not enforce that constra
On ons, 2010-09-01 at 16:22 +0200, Fabien COELHO wrote:
> I'm suggesting uniqueness in the "information_schema", which can be
> provided independently by some tweaking in the view construction, I
> think, for instance by adding the oid of the constraint or maybe the
> table_name.
The view is defi
Well, the answer is that Jeff's instinct was right: the dump and reload
isn't reproducing the original data exactly. It's not our fault though,
it's a postgis bug. Observe:
gisttest2=# select ST_expand(setsrid(makepoint(-122.50367,37.74189),4326),
0.4);
Tom Lane wrote:
So these two geometry values do not overlap in the original database,
but they do overlap in the clone, apparently because the output
representation of geometry doesn't result in an exact reconstruction
of the value. Somebody better complain over in the postgis lists.
Thanks f
Excerpts from Euler Taveira de Oliveira's message of mié sep 01 10:18:10 -0400
2010:
> Tom Lane escreveu:
> > I'm not inclined to go and retroactively document that these spellings
> > are possible but deprecated in the old branches. I think that would
> > just confuse matters even more.
>
> Is
Dear Peter,
I'm suggesting uniqueness in the "information_schema", which can be
provided independently by some tweaking in the view construction, I
think, for instance by adding the oid of the constraint or maybe the
table_name.
The view is defined by the SQL standard.
No. The result of the
