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
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 qu
"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 reason
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 persp
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
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 s
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 cor
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 comple
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 st
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
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 a
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" <[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
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 functions
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, indexe
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
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
spec
"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
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 t
Well, I certainly don't think a setof 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 simple queries
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
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 th
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
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
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
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 thin
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
"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 fu
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?
> >>
> >>
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 handy
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 curren
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 serv
"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
Hello,
I can guess some of these:
pg_get_tabledef() : Would take a table name and return the columns and
associated types
pg_get_acldef(): Would take an object name and return the associated
roles and permissions for the object
pg_get_typedefault(): This one I am unsure about
pg_get_attrd
34 matches
Mail list logo