> >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 own
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
que
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 f
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
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
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 o
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'
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 g
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
On Tue, 2003-10-21 at 00:08, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> 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
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 co
Christopher Kings-Lynne <[EMAIL PROTECTED]> 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 o
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.
Forwar
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
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
> 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 int
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 fucti
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
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 d
19 matches
Mail list logo
