Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to
Mark Kirkwood wrote:
Jim C. Nasby wrote:
Here's the relevant thread:
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00756.php
The intention is to flesh out the existing pg_get_blahdef functions,
such as pg_get_viewdef(). This clearly means that the functions should
output a
On Mon, Jun 12, 2006 at 08:49:00AM -0400, Andrew Dunstan wrote:
Yes ... except that I don't see any good reason to have these in a
contrib module and keep, say, pg_get_viewdef() in core. They belong
together, I think, and I don't think they represent so much bloat that
having them in core
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all, but surely
the
Jim C. Nasby wrote:
The only reason I've been able to think of for why pg_dump wouldn't use
a *back end* function for this is because it would then be limited to
dumping in the format provided by that backend, which could become an
issue when upgrading. If that is in fact a problem, it might be
Before we pull pg_dump to bits let's identify some actual benefit from
doing so. If you look at the code you will see that it is more than
somewhat complex. A large scale move like you are proposing would be
very high risk, IMNSHO.
From a person who deals with customer migrations daily
Jim C. Nasby [EMAIL PROTECTED] writes:
One thing that I think should be clarified... why wouldn't pg_dump be
able to use these functions? Is it because of version compatability?
This has already been gone over more than once in this thread, let
alone the prior one, but here are some reasons:
*
Joshua D. Drake wrote:
What is easier?
test=# select column_name, data_type from columns where table_schema !=
'pg_catalog' and table_name = 'email';
\d email
So, would you change psql's \d logic to use the new function? While
answering that, consider that you'd lose the ability to query
On Sat, Jun 10, 2006 at 08:20:15PM -0700, Joshua D. Drake wrote:
Well, the argument against changing pg_dump is that it would impact the
ability to use the newer version of pg_dump with older backends (which
would be lacking these functions).
ISTM what would be best is to add the functions
Joshua D. Drake wrote:
Well, the argument against changing pg_dump is that it would impact the
ability to use the newer version of pg_dump with older backends (which
would be lacking these functions).
ISTM what would be best is to add the functions to the backend, and add
a TODO or comments
Well, I certainly don't think a setof name, type is adequate for
pg_get_tabledef(). What about constraints? And what you are suggesting
can probably be got by very simple queries against either the catalog or
the information schema, and seems to me to have little value.
Well it isn't
CREATE TABLE foo (id serial);
I mean, I can do either but I would like to get a clear definition of
what we are looking for here. Maybe:
pg_get_tabledef is the actual SQL and pg_get_tabledesc() is the column,
datatype output?
I guess I don't see the advantage of putting pg_dump -s -t in
Joshua D. Drake [EMAIL PROTECTED] writes:
If all you want is column, datatype, why not just use info_schema, or
newsysviews? Or even the base catalogs?
Where do I look in the info_schema? How do I know exactly what I need?
What is newsysviews?
Exactly the same arguments can be made against
Joshua D. Drake wrote:
Name and datatype was just an example. I am trying to get people to
actually provide feedback (thank you). Andrew brought up that also
including the constraints would be a good idea which I agree.
You also need rules, triggers, inheritance, indexes, primary key
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
If all you want is column, datatype, why not just use info_schema, or
newsysviews? Or even the base catalogs?
Where do I look in the info_schema? How do I know exactly what I need?
What is newsysviews?
Exactly the same arguments can
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Name and datatype was just an example. I am trying to get people to
actually provide feedback (thank you). Andrew brought up that also
including the constraints would be a good idea which I agree.
You also need rules, triggers, inheritance,
Hello,
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
Is it to return the CREATE statements for each (where applicable)?
Is it just to create backend versions of the the identical
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all, but surely
the first item of work for
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all, but surely
the first
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all,
On Mon, Jun 12, 2006 at 03:47:13PM +1200, Mark Kirkwood wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing
Jim C. Nasby wrote:
On Mon, Jun 12, 2006 at 03:47:13PM +1200, Mark Kirkwood wrote:
Keeping 'em separate makes sense to me:
1/ API (or info schema views) provides the required data (e.g column
details for a table).
2/ client (e.g. pg_dump) decides what to do with it (e.g. construct a
CREATE
Joshua D. Drake [EMAIL PROTECTED] writes:
So could I get some further definition?
There are two fairly strong reasons for NOT trying to push more logic
into the backend from pg_dump:
1. It would remove the freedom we currently have to make pg_dump adapt
dumps from old servers to match newer
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
So could I get some further definition?
There are two fairly strong reasons for NOT trying to push more logic
into the backend from pg_dump:
1. It would remove the freedom we currently have to make pg_dump adapt
dumps from old servers
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
So could I get some further definition?
There are two fairly strong reasons for NOT trying to push more logic
into the backend from pg_dump:
1. It would remove the freedom we currently have to make
Maybe I am misunderstanding the TODO (which is entirely possible due to
the complete lack of documentation on the feature) but I *thought* all I
was going to do was create 6 functions that could be called to get
various useful information?
For example, pg_get_tabledef() would be a very
Joshua D. Drake wrote:
Maybe I am misunderstanding the TODO (which is entirely possible due to
the complete lack of documentation on the feature) but I *thought* all I
was going to do was create 6 functions that could be called to get
various useful information?
For example,
Joshua D. Drake [EMAIL PROTECTED] writes:
O.k. so now what I am getting from this thread is, the functions exist
now in pg_dump but we want to pull them out of pg_dump and push them
into the backend?
That's exactly what I *don't* want to do. If you can think of a
use-case for these
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
O.k. so now what I am getting from this thread is, the functions exist
now in pg_dump but we want to pull them out of pg_dump and push them
into the backend?
That's exactly what I *don't* want to do. If you can think of a
use-case
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
O.k. so now what I am getting from this thread is, the functions exist
now in pg_dump but we want to pull them out of pg_dump and push them
into the backend?
That's exactly what I *don't* want to do. If you can think of a
On Sat, Jun 10, 2006 at 07:33:54PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
O.k. so now what I am getting from this thread is, the functions exist
now in pg_dump but we want to pull them out of pg_dump and push them
into the backend?
Tom Lane said:
Joshua D. Drake [EMAIL PROTECTED] writes:
O.k. so now what I am getting from this thread is, the functions exist
now in pg_dump but we want to pull them out of pg_dump and push them
into the backend?
That's exactly what I *don't* want to do. If you can think of a
use-case
Well, the argument against changing pg_dump is that it would impact the
ability to use the newer version of pg_dump with older backends (which
would be lacking these functions).
ISTM what would be best is to add the functions to the backend, and add
a TODO or comments to pg_dump indicating that
33 matches
Mail list logo
