Re: 7.2 stuff

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Tell me what I should do for 7.2...

At this point, none of these are on the radar screen for 7.2; we are in
"get the release out" mode, and anything that's not a critical bug fix
need not apply.  But here are some comments for 7.3 and beyond.

> Is there a pg_get_* function for getting foreign key definitions yet?

No, but it seems like possibly a good idea.  We should try to move away
from applications looking directly at the system catalogs, and introduce
some layer of indirection so that catalog changes don't break so many
things.  pg_get_xxx functions are one approach.  Peter E. has suggested
that implementing the SQL92 informational views might be a better (more
standards-compliant) way of providing that indirection.  That's cool to
the extent that it works, but I wonder whether we won't find that the
SQL92 views omit important Postgres extensions.  Anyway, this is a
long-term project.

> It looked to me that pgclass.relfkeys wasn't ever being set or updated.  Is
> this true/correct?

I cannot find any references to it in the code, either.

> For instance, I would like to be able to pg_dump all the diary tables in one
> go.
> ie. pg_dump -t diary_\* audb > dump.sql
> Don't know if there would be widespread enough demand for this feature
> tho...

I've seen requests for that before ... and I don't think they were all
from you ;-).  Seems like a reasonable wishlist item to me.

> * DOCUMENT PG_TRIGGER
> - Doesn't seem to be in the system catalog documentation...
> Yeah, pg_trigger does not appear on this page:

It's in the current sources.  Perhaps you're looking at an obsolete
mirror?

> Basically I was getting the impression that the command.c was getting big
> and fat and that it might be nice to split all the ALTER* commands into an
> alter.c or something.

Cool with me.  We often fail to spend enough effort on code
beautification projects; that hurts the maintainability of the project
in the long run.  Feel free to devise and implement a better division
of the ALTER code.  (And as I think we already talked about, it'd also
be cool to try to merge the common infrastructure of the ALTER commands
somehow.  I don't like umpteen copied-and-pasted versions of the same
code, either ...)
        regards, tom lane