Being able to export to other dbs will get us _more_ users, not less.
Without some type of corresponding import utility that seems logically false.
Nope. Consider it like this. How many companies are going to move to
PostgreSQL from Oracle if they cannot dump their data back to Oracle as
a fai
On Friday 13 August 2004 00:13, Christopher Kings-Lynne wrote:
> > That should make exporting to other DBs a lot easier. Of course, that
> > could be cutting our own throat too ...
>
> It won't make any difference to anything. You can already dump in
> INSERT format.
>
> Being able to export to ot
hackers,
here's another bunch of message strings translated into sk_SK.
Cheers
Zoltan
pg_dump-sk.po.bz2
Description: BZip2 compressed data
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.
On Fri, 13 Aug 2004, Bruce Momjian wrote:
>
> Where are we on this?
>
> ---
>
> Tom Lane wrote:
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > >> Yeah, those are all bug fixes and okay for post-beta I think. But
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
And anyway, the DD
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> That should make exporting to other DBs a lot easier. Of course, that
>> could be cutting our own throat too ...
> It won't make any difference to anything. You can already dump in
> INSERT format.
And anyway, the DDL peculiarities would b
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Did we resolve this?
No, it's an open issue.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining col
The other tablespace problem is if you drop a tablespace that schema in
another db uses, it's broken still I think.
Chris
Bruce Momjian wrote:
Where are we on this?
---
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTE
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
Being able to export to other dbs will get us _more_ users, not less.
Chris
---(
Where are we on this?
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >> Yeah, those are all bug fixes and okay for post-beta I think. But which
> >> two tablespace failures are you thinking of e
Did we resolve this?
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Maybe we could avoid removing it until the next checkpoint? Or is that
> > not enough. Maybe it could stay there forever :
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
[snip]
* Export to other database (eg. Oracle, MySQL and DB2) formats
This strikes me as a can of worms, or to mix metaphors a bit, a rathole
from which we might never emerge.
I did have a thought the other day - now
Yep, a whole section for pg_dump features and bugs would be nice.
Bruce Momjian wrote:
Do you want any of these added to the TODO?
---
Christopher Kings-Lynne wrote:
And I forgot to add:
* Allow dumping/restoring of any number
Do you want any of these added to the TODO?
---
Christopher Kings-Lynne wrote:
> And I forgot to add:
>
> * Allow dumping/restoring of any number of specific objects and types
>
> Chris
>
> Christopher Kings-Lynne wrote:
Added to TODO:
o Add ALTER INDEX that works just like ALTER TABLE already does
on an index
---
Robert Treat wrote:
> On Tuesday 10 August 2004 22:13, Christopher Kings-Lynne wrote:
> > > What I mean here
On Tuesday 10 August 2004 22:13, Christopher Kings-Lynne wrote:
> > What I mean here is that I think it would be in our best interests to
> > define the syntax for any new operation to be as easily guessed as
> > possible. I believe that ALTER INDEX would be more easily guessed by
> > more people
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index column
I think we should add another column to this table:
http://developer.postgresql.org/docs/postgres/errcodes-appendix.html
And explicitly list out all the exception names.
I think that would be clearer and easier than having a paragraph they
need to read that says 'just use underscores'...
Also, I
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index columns
* Replace crude DELETE FROM way of dumping cleaning of users and groups
with separate DROP commands
* Add dumping and restori
At 11:42 PM 12/08/2004, Tom Lane wrote:
That's a possibility, but I'd rather work around it by finding a way for
pg_restore not to need to parse the dollar-quoted literal in the first
place.
Two possibilities:
1) Parse the tags (I have the code working): it's not that hard, the only
trick bit bein
OK, I added this TODO:
* Allow finer control over the caching of prepared query plans
Currently, queries prepared via the libpq API are planned on first
execute using the supplied parameters --- allow SQL PREPARE to do the
same. Also, allow control over replanning prepared queries either
Dear Hans,
>
> Robert,
>
> Are you planning to use Intel's C compiler in production?
> We tried that some time ago and corrupted our database cluster almost
> instantly (for some reason we have not investigated any further).
> I highly recommend to do some stress testing to see if everything wor
Kenneth Marshall <[EMAIL PROTECTED]> writes:
> On Thu, Aug 12, 2004 at 09:58:56AM -0400, Tom Lane wrote:
>> How would a read-only action work to block out the checkpoint?
> The latch+version number is use by the checkpoint process. The
> other processes can do a read of the latch to determine if i
Kenneth Marshall <[EMAIL PROTECTED]> writes:
> Would it be possible to use a latch + version number in
> this case to minimize this problem by allowing all but the checkpoint to
> perform a read-only action on the latch?
How would a read-only action work to block out the checkpoint?
More generall
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I had a thought that might short-circuit this - do we even need pg_dump to
> use dollar quoting for non-text output, such as is required by pg_restore?
That's a possibility, but I'd rather work around it by finding a way for
pg_restore not to need to
Hi Tom,
Just re-installed a new version of Postgres 7.3.4 on a *clean* version
of Mandrake 9.2, which seemed to work well. The reference to the
xlateSqlType symbol is gone from plpgsql.so.
All postgres packages installed came from the original Mandrake 9.2 CD.
After a little search plpgsql.so
With help from Christopher I've made some other tests.
Neither 7.4 nor 7.5/8.0 pg_dump are able to detect the
error. Here is a summary:
The produced dump creates a SEQUENCE SET call with no
corresponding SEQUENCE or TABLE SCHEMA creating the
sequence. No Error or warning is issued at dump time,
n
In article <[EMAIL PROTECTED]>,
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Right, the reason it's important is that there are some things now that
> are potentially tied together. If you have table A with rows A1,...,An and
> table B with rows B1,...,Bm and the delete join condition gives the two
Philip Warner said:
> At 12:15 PM 12/08/2004, Tom Lane wrote:
>>You might need to bite the bullet and implement a flex
>>lexer.
>
> I'd like to avoid this if I can; AFAICT, for statement detection on
> pg_restore, I can require white space before the $tag. Since I also
> skip over all quoted text,
Dear Peter,
> Am Dienstag, 10. August 2004 17:55 schrieb Fabien COELHO:
> > (1) all makefiles in contrib include directly "src/Makefile.global" which
> > is generated by configure, although it is already included by the
> > "src/makefiles/pgxs.mk" makefile anyway, so it seems to me that i
30 matches
Mail list logo
