Fabien COELHO wrote:
>
> > If you're going to use something which is PostgreSQL-specific, you may
> > as well write your own views or use the "native" tables and views
> > directly.
>
> I wish I could write portable code, if possible:-)
>
> I'm basically writing views on top of the information
On Sun, Sep 12, 2010 at 12:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 31, 2010 at 10:46 AM, Tom Lane wrote:
>>> We are not going to try to enforce uniqueness. This has been debated
>>> before, and most people like the current behavior just fine, or at least
>>> better than the
Robert Haas writes:
> On Tue, Aug 31, 2010 at 10:46 AM, Tom Lane wrote:
>> We are not going to try to enforce uniqueness. This has been debated
>> before, and most people like the current behavior just fine, or at least
>> better than the alternatives.
> Really? I thought the issue was that no
On Tue, Aug 31, 2010 at 10:46 AM, Tom Lane wrote:
> We are not going to try to enforce uniqueness. This has been debated
> before, and most people like the current behavior just fine, or at least
> better than the alternatives.
Really? I thought the issue was that no one had figured out how to
On fre, 2010-09-03 at 13:53 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Fabien COELHO's message of vie sep 03 13:39:19 -0400 2010:
> >> I tried to explained that I'm analyzing other people's schemas. I cannot
> >> ask all other people on the planet to rewrite their schemas,
If you're going to use something which is PostgreSQL-specific, you may
as well write your own views or use the "native" tables and views
directly.
I wish I could write portable code, if possible:-)
I'm basically writing views on top of the information_schema under the
assumption that what i
If you're going to use something which is PostgreSQL-specific, you may as
well write your own views or use the "native" tables and views directly.
I wish I could write portable code, if possible:-)
I'm basically writing views on top of the information_schema under the
assumption that what is
Maybe you shouldn't be using the information_schema in the first place.
Sure, I could write non standard code for every database instead of trying
to write a portable code which work on all of them directly:-)
I think that trying to do the portable way, under the assumption that the
standa
Alvaro Herrera writes:
> Excerpts from Fabien COELHO's message of vie sep 03 13:39:19 -0400 2010:
>> I tried to explained that I'm analyzing other people's schemas. I cannot
>> ask all other people on the planet to rewrite their schemas, I pick them
>> as they are.
> Maybe you shouldn't be usin
Excerpts from Fabien COELHO's message of vie sep 03 13:39:19 -0400 2010:
> I tried to explained that I'm analyzing other people's schemas. I cannot
> ask all other people on the planet to rewrite their schemas, I pick them
> as they are.
Maybe you shouldn't be using the information_schema in th
Well, one must choose between to evil:
Yeah, exactly. I think that the current tradeoff is just fine.
Hmmm. I think exactly the contrary. There is no point in having a non
reliable feature.
ISTM that very few people use the information schema, and if the query
results is not reliable, i
Tom Lane wrote:
> Yeah, exactly. I think that the current tradeoff is just fine.
> If you want SQL-standard behavior, pick SQL-standard constraint
> names, and there you are.
I see that as the crux if it -- the current implementation *allows*
standard-conforming behavior, even though it doesn
Fabien COELHO writes:
>> Note that (2) fails for long names; you have to do something to
>> compress to NAMEDATALEN.
> Indeed.
> What if the type is changed to TEXT? It is just a view after all.
> How important is it to stick to "sql_identifier"?
It's a view defined by the SQL standard, and one
Dear Tom,
Still for the sake of argument:
Note that (2) fails for long names; you have to do something to
compress to NAMEDATALEN.
Indeed.
What if the type is changed to TEXT? It is just a view after all.
How important is it to stick to "sql_identifier"?
The big problem with either of th
Fabien COELHO writes:
> (1) use the OID as the "constraint name" everywhere, it would work, it
> would not look so good for display, but it is simple and fast.
> (2) otherwise something built on top of . To be on the
> safe side, I would build a string (sql_identifier?) with something like:
>
Hallo,
\d information_schema.referential_constraints
View "information_schema.referential_constraints"
...
FROM pg_namespace ncon
JOIN pg_constraint con ON ncon.oid = con.connamespace
JOIN pg_class c ON con.conrelid = c.oid
Well, for the sake of argument, how would you pro
On tor, 2010-09-02 at 07:54 +0200, Fabien COELHO wrote:
> > We cannot change it.
>
> Yes we can! It, it is 100% postgresql:
>
> \d information_schema.referential_constraints
>View "information_schema.referential_constraints"
>...
> FROM pg_namespace ncon
> JOIN pg_constraint co
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
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
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
Fabien COELHO writes:
> 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 e
Hello,
I haven't found a bug management system about postgresql, so here is a
mail. Maybe this issue was already reported, sorry if it is the case.
I have seen anything about the information_schema in pg todo list.
This is tested on postgresql 8.4.4.
The REFERENTIAL_CONSTRAINTS table in the
22 matches
Mail list logo
