Hi,

Is there demand for modifying psql to work against previous backends,
pg_dump-style?

I feel like looking into it, but tell me if I'm wasting my time...

Chris

Search Discussions

  • Alvaro Herrera at Oct 21, 2003 at 1:35 am

    On Tue, Oct 21, 2003 at 09:26:12AM +0800, Christopher Kings-Lynne wrote:

    Is there demand for modifying psql to work against previous backends,
    pg_dump-style?

    I feel like looking into it, but tell me if I'm wasting my time...
    Please do ...

    I wonder what would it take. It only needs a different set of queries
    to obtain info from the syscatalogs, or is it more involved?

    --
    Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
    Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
    No dijo "Hello New Jersey\n", ni "Hello USA\n".
  • Christopher Kings-Lynne at Oct 21, 2003 at 1:44 am

    I feel like looking into it, but tell me if I'm wasting my time...

    Please do ...

    I wonder what would it take. It only needs a different set of queries
    to obtain info from the syscatalogs, or is it more involved?
    Looks fairly straightforward to me. Just need to get backend version
    out. Maybe handle v2 protocol again. Then just have different SQL for
    different backends.

    Chris
  • Matthew T. O'Connor at Oct 21, 2003 at 2:26 am

    On Mon, 2003-10-20 at 21:45, Christopher Kings-Lynne wrote:
    Looks fairly straightforward to me. Just need to get backend version
    out. Maybe handle v2 protocol again. Then just have different SQL for
    different backends.
    Going forward if we put the sql for all the psql commands into fuctions,
    then psql could be less tied to the backend version. I thought this was
    a TODO item already.
  • Rod Taylor at Oct 21, 2003 at 2:30 am

    Going forward if we put the sql for all the psql commands into fuctions,
    then psql could be less tied to the backend version. I thought this was
    a TODO item already.
    The tricky part seems to be dealing with i10n issues since the text to
    translate would be release specific it needs to go into the backend --
    but that isn't so nice.
  • Christopher Kings-Lynne at Oct 21, 2003 at 2:37 am

    The tricky part seems to be dealing with i10n issues since the text to
    translate would be release specific it needs to go into the backend --
    but that isn't so nice.
    Why tricky? I'm just going to make the 7.5 psql utility work against
    previous versions of postgresql. Any strings in that utility are
    translatable like any other.

    Chris
  • Rod Taylor at Oct 21, 2003 at 3:01 am

    On Mon, 2003-10-20 at 22:39, Christopher Kings-Lynne wrote:
    The tricky part seems to be dealing with i10n issues since the text to
    translate would be release specific it needs to go into the backend --
    but that isn't so nice.
    Why tricky? I'm just going to make the 7.5 psql utility work against
    previous versions of postgresql. Any strings in that utility are
    translatable like any other.
    I suppose if all you want is backward compatibility which makes sense
    for pg_dump, but surely psql should be forward thinking.

    Normally it's old clients with new server, not the other way around --
    at least with big companies it seems easier to get a server upgraded
    than everyones desktop.

    Forward looking means pulling the available commands, queries, etc from
    the backend. It actually works quite well (submitted a patch quite a
    while ago) in all respects except string translation.
  • Christopher Kings-Lynne at Oct 21, 2003 at 3:14 am

    I suppose if all you want is backward compatibility which makes sense
    for pg_dump, but surely psql should be forward thinking.

    Normally it's old clients with new server, not the other way around --
    at least with big companies it seems easier to get a server upgraded
    than everyones desktop.

    Forward looking means pulling the available commands, queries, etc from
    the backend. It actually works quite well (submitted a patch quite a
    while ago) in all respects except string translation.
    Hmmm...string translation really is the bugger, isn't it. I had only
    planned to do backwards compatibility really...

    It had occurred to me that we could move support for each version of the
    backend into a shared lib.

    eg. libpsql70.so, libpsql71.so, etc.

    Then all we do is load the appropriate lib and call functions in it. To
    support a newer version of postgres, you just need to drop in the latest
    .so or something.

    Chris
  • Tom Lane at Oct 21, 2003 at 4:09 am

    Christopher Kings-Lynne writes:
    It had occurred to me that we could move support for each version of the
    backend into a shared lib.
    eg. libpsql70.so, libpsql71.so, etc.
    Then all we do is load the appropriate lib and call functions in it. To
    support a newer version of postgres, you just need to drop in the latest
    .so or something.
    It doesn't strike me that that actually buys you anything, except
    perhaps guaranteeing that psql cannot function on shared-lib-less
    platforms. The clear facts at the moment are that an older psql
    cannot be promised to have full functionality with newer backends.
    Saying "well it'll work if you install a newer shared library" does
    not buy a thing that I can see --- it's no more effort to install
    a whole new psql, is it?

    Rod's ideas about pushing psql functionality out to the backend
    (via special views etc) could ameliorate the forward-compatibility
    problem to some extent. But we usually find ourselves fixing psql
    in more places than describe.c for each release, so I'm not convinced
    there's a full solution available in that direction either.

    regards, tom lane
  • Rod Taylor at Oct 21, 2003 at 12:53 pm

    On Tue, 2003-10-21 at 00:08, Tom Lane wrote:
    Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    It had occurred to me that we could move support for each version of the
    backend into a shared lib.
    eg. libpsql70.so, libpsql71.so, etc.
    Then all we do is load the appropriate lib and call functions in it. To
    support a newer version of postgres, you just need to drop in the latest
    .so or something.
    It doesn't strike me that that actually buys you anything, except
    perhaps guaranteeing that psql cannot function on shared-lib-less
    platforms. The clear facts at the moment are that an older psql
    cannot be promised to have full functionality with newer backends.
    Saying "well it'll work if you install a newer shared library" does
    not buy a thing that I can see --- it's no more effort to install
    a whole new psql, is it?

    Rod's ideas about pushing psql functionality out to the backend
    (via special views etc) could ameliorate the forward-compatibility
    problem to some extent. But we usually find ourselves fixing psql
    in more places than describe.c for each release, so I'm not convinced
    there's a full solution available in that direction either.
    There is always the biggest evil of all... Putting SHOW / DESCRIBE /
    HELP commands into the backend itself. I'm sure the pgAdmin group likes
    that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql
    backward or forward compatible should go an additional step to assist
    other frontends as well.
  • Andreas Pflug at Oct 21, 2003 at 1:03 pm

    Rod Taylor wrote:

    I'm sure the pgAdmin group likes that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql backward or forward compatible should go an additional step to assist other frontends as well.
    While I can agree on the statements that frontends like backend support
    functions, in the case of tables for pgAdmin3 helper functions/views
    don't seem too helpful. pgAdmin3 will not only try to display all
    supported backend versions (currently 7.3, 7.4) correctly, but also
    enable/disable additional functionality. Having different queries for
    different backends is just a small part of the game, and the easiest one
    too. Hiding the backend differences behind views or functions wouldn't
    help too much.

    Regards,
    Andreas
  • Rod Taylor at Oct 21, 2003 at 1:22 pm

    On Tue, 2003-10-21 at 09:03, Andreas Pflug wrote:
    Rod Taylor wrote:
    I'm sure the pgAdmin group likes that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql backward or forward compatible should go an additional step to assist other frontends as well.
    While I can agree on the statements that frontends like backend support
    functions, in the case of tables for pgAdmin3 helper functions/views
    don't seem too helpful. pgAdmin3 will not only try to display all
    supported backend versions (currently 7.3, 7.4) correctly, but also
    enable/disable additional functionality. Having different queries for
    different backends is just a small part of the game, and the easiest one
    too. Hiding the backend differences behind views or functions wouldn't
    help too much.
    Of course, psql has the same issue in hiding functionality that doesn't
    exist. My biggest beef is the psql help is often misleading if you're
    connected to a different backend.

    This would need to be a part of a solution if we're going to get
    anything out of it.
  • Andreas Pflug at Oct 21, 2003 at 1:33 pm

    Rod Taylor wrote:
    Of course, psql has the same issue in hiding functionality that doesn't
    exist. My biggest beef is the psql help is often misleading if you're
    connected to a different backend.

    This would need to be a part of a solution if we're going to get
    anything out of it.
    No problem, let's put the complete documentation into the server!
    Something like pg_help(text, int2) e.g. SELECT pg_help('CREATE TABLE
    foo(..)', PG_HTML);

    Regards,
    Andreas
  • Rod Taylor at Oct 21, 2003 at 1:49 pm

    On Tue, 2003-10-21 at 09:33, Andreas Pflug wrote:
    Rod Taylor wrote:
    Of course, psql has the same issue in hiding functionality that doesn't
    exist. My biggest beef is the psql help is often misleading if you're
    connected to a different backend.

    This would need to be a part of a solution if we're going to get
    anything out of it.
    No problem, let's put the complete documentation into the server!
    Something like pg_help(text, int2) e.g. SELECT pg_help('CREATE TABLE
    foo(..)', PG_HTML);
    That would certainly be a part of it. I haven't put much thought outside
    of the help / describe / tab completion portions.
  • Christopher Kings-Lynne at Oct 22, 2003 at 1:22 am

    There is always the biggest evil of all... Putting SHOW / DESCRIBE /
    HELP commands into the backend itself. I'm sure the pgAdmin group likes
    that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql
    backward or forward compatible should go an additional step to assist
    other frontends as well.
    All that means for phpPgAdmin and pgAdmin is that we'll have to support
    5 different queries :P

    We could use information_schema...

    Chris
  • Rod Taylor at Oct 22, 2003 at 2:23 am

    On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:
    There is always the biggest evil of all... Putting SHOW / DESCRIBE /
    HELP commands into the backend itself. I'm sure the pgAdmin group likes
    that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql
    backward or forward compatible should go an additional step to assist
    other frontends as well.
    All that means for phpPgAdmin and pgAdmin is that we'll have to support
    5 different queries :P
    Yes, but I would hope it stops at 5, and over the next 3 years you don't
    have 10 different query forms.
    We could use information_schema...
    Nay... I would expect a PostgreSQL specific information_schema to get
    just as much mucking around as the system tables, which means you are
    still maintaining a set of queries per release.
  • Andreas Pflug at Oct 23, 2003 at 10:23 am

    Rod Taylor wrote:
    On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:

    There is always the biggest evil of all... Putting SHOW / DESCRIBE /
    HELP commands into the backend itself. I'm sure the pgAdmin group likes
    that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql
    backward or forward compatible should go an additional step to assist
    other frontends as well.
    All that means for phpPgAdmin and pgAdmin is that we'll have to support
    5 different queries :P
    Yes, but I would hope it stops at 5, and over the next 3 years you don't
    have 10 different query forms.


    We could use information_schema...
    Nay... I would expect a PostgreSQL specific information_schema to get
    just as much mucking around as the system tables, which means you are
    still maintaining a set of queries per release.
    The problem about information_schema is that it's restricted to show
    objects of the owner only. This is by spec, but will prevent us from
    seeing all we need.
    This might get better if we get rules.

    Regards,
    Andreas
  • Rod Taylor at Oct 23, 2003 at 1:09 pm

    Nay... I would expect a PostgreSQL specific information_schema to get
    just as much mucking around as the system tables, which means you are
    still maintaining a set of queries per release.
    The problem about information_schema is that it's restricted to show
    objects of the owner only. This is by spec, but will prevent us from
    seeing all we need.
    This might get better if we get rules.
    Well... That, and it only describes about 1/2 of the features in
    PostgreSQL.
  • Christopher Kings-Lynne at Oct 22, 2003 at 1:22 am

    There is always the biggest evil of all... Putting SHOW / DESCRIBE /
    HELP commands into the backend itself. I'm sure the pgAdmin group likes
    that idea (they're probably tired of maintaining 4 different versions of
    queries for getting a list of tables). Any solution to make psql
    backward or forward compatible should go an additional step to assist
    other frontends as well.
    Really, is the problem with translation that you might want different
    translation in your client psql compared to the server?

    Chris
  • Rod Taylor at Oct 21, 2003 at 4:26 am

    On Mon, 2003-10-20 at 23:15, Christopher Kings-Lynne wrote:
    I suppose if all you want is backward compatibility which makes sense
    for pg_dump, but surely psql should be forward thinking.

    Normally it's old clients with new server, not the other way around --
    at least with big companies it seems easier to get a server upgraded
    than everyones desktop.

    Forward looking means pulling the available commands, queries, etc from
    the backend. It actually works quite well (submitted a patch quite a
    while ago) in all respects except string translation.
    Hmmm...string translation really is the bugger, isn't it. I had only
    planned to do backwards compatibility really...
    The way around it is to have a 'description' query that describes how to
    draw the table (title, field names) and the content query that supplies
    the content for the table.

    I just haven't tried it out yet.
    Then all we do is load the appropriate lib and call functions in it. To
    support a newer version of postgres, you just need to drop in the latest
    .so or something.
    That really isn't different than putting queries into the client.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 21, '03 at 1:24a
activeOct 23, '03 at 1:09p
posts20
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase