It would be very helpful if the COPY command could be expanded
in order to provide positional parameters.
I noticed that it didn't a while back and it can really hurt
someone when they happen to try to use pg_dump to move data
from one database to another database and they happened to
create the
On Sun, 29 Apr 2001, Bruce Momjian wrote:
I think parsing the file contents is too hard. The database would have
to be running and I would use psql.
I don't know, I recovered someone's database using a raw connection ...
wasn't that difficult once I figured out the format *shrug*
Bruce Momjian [EMAIL PROTECTED] wrote:
I can see Interbase, MySQL, and SAP DB as being three database that
would be worth researching. I am willing to assist anyone who wants to
give it a try. I have all the sources here myself. I even have old
University Ingres, Mariposa, and Postgres
Guys,
while analyzing some stuff I came across something that looks
like a bug in the ODBC driver to me. I'm by far not the ODBC
user I should be to fix it, so could someone else please take
another look?
The symptom is when the driver is in AUTOCOMMIT=OFF, closing
the
On Mon, 30 Apr 2001, Alfred Perlstein wrote:
Basically:
COPY webmaster FROM stdin;
could become:
COPY webmaster FIELDS id, name, ssn FROM stdin;
We'd need some way of making field name dumping optional, because
one of the nice things about not having the field names appear is that
I can
Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.
But why does
Horst Herb wrote:
I downloaded it. The directories are two characters in length, the
files are numbers, and it is a mixture of C++, Python, and Pascal. Need
I say more. :-)
1.) What is wrong with a mixture of C++, Python and Pascal? Nothing IMHO.
2.) The directory structure is
Vince Vielhaber [EMAIL PROTECTED] writes:
Oh, you did a direct postgres backend connect. Yes, that will work
fine. Good idea if the postmaster is down. I originally thought you
meant reading the pg_class file raw. Of course, that would be really
hard because there is no way to know what
Thomas Lockhart [EMAIL PROTECTED] writes:
But it is possible, under many circumstances, for query optimization to
be a benefit for a many-table query. The docs indicate that explicit
join syntax bypasses that, even for inner joins, so you may find that
this syntax is a net loss in performance
It might be worth making a simple utility (could be based on Bryan
White's pg_check) to grovel through the raw pg_class bits and extract
relfilenode info the hard way. You'd only need it in certain disaster
scenarios, but when you did need it you'd need it bad.
So far we have not seen a
Thomas Lockhart writes:
Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to
Alfred Perlstein [EMAIL PROTECTED] writes:
It would be very helpful if the COPY command could be expanded
in order to provide positional parameters.
I think it's a bad idea to try to expand COPY into a full-tilt data
import/conversion utility, which is the direction that this sort of
Thomas Lockhart [EMAIL PROTECTED] writes:
Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a
* Tom Lane [EMAIL PROTECTED] [010430 08:37] wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
It would be very helpful if the COPY command could be expanded
in order to provide positional parameters.
I think it's a bad idea to try to expand COPY into a full-tilt data
import/conversion
Alfred Perlstein [EMAIL PROTECTED] writes:
It would be very helpful if the COPY command could be expanded
in order to provide positional parameters.
I think it's a bad idea to try to expand COPY into a full-tilt data
import/conversion utility, which is the direction that this sort of
Karen saw me importing data into a database using pgaccess.
Again, this could be useful to someone that it is not a superuser.
But only superusers can use pgaccess. What a shame :-(
Fernando
P.S.: pgaccess has a much more limited import facility - only text files
and you can only change the
Tom Lane wrote:
Most likely, you removed the user that owned ro_ellipse. Create a
user with the same usesysid shown as ro_ellipse's relowner, or else
change the relowner field to point at an extant user.
I believe 7.1's pg_dump copes with this sort of thing more gracefully...
Thomas, what do you think of the persistent reports of date conversion
problems at DST boundaries, eg, Ayal Leibowitz's report today in
pgsql-bugs? I cannot reproduce any such problem --- and my local
timezone database claims that MET DST transitions are the last week of
March, never the
Hehe, match the docs? The docs used to be perfectly accurate until you
changed them.
;)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
From: Tom Lane [EMAIL PROTECTED]
Magnus Naeslund\(f\) [EMAIL PROTECTED] writes:
Where do get a listing of what PQftype() can return to me?
select oid, typname from pg_type
regards, tom lane
Does these change often?
Or could i do like the ODBC driver, autogenerate a .h out of that table.
From: Tom Lane [EMAIL PROTECTED]
[snip]
The system type OIDs are stable. User-defined types would probably have
a new OID after a dump and reload.
Or could i do like the ODBC driver, autogenerate a .h out of that table.
I would not recommend relying on compiled-in OID knowledge for any
Magnus Naeslund\(f\) [EMAIL PROTECTED] writes:
Where do get a listing of what PQftype() can return to me?
select oid, typname from pg_type
Does these change often?
The system type OIDs are stable. User-defined types would probably have
a new OID after a dump and reload.
Or could i do
On Mon, 30 Apr 2001, Tom Lane wrote:
I think it'd be better to put effort into an external data translation
utility that can deal with column selection, data reformatting, CR/LF
conversion, and all those other silly little issues that come up when
you need to move data from one DBMS to
The Hermit Hacker [EMAIL PROTECTED] writes:
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
FWIW, I've finished committing all the bug fixes I have pending.
Bruce Momjian [EMAIL PROTECTED] writes:
We do have that not-quite-done QNX4 port patch in hand. Perhaps we
should give Bernd another day to respond to the comments on that and
squeeze it into 7.1.1.
There will surely be a 7.1.2. I vote against waiting for it.
Possibly, but one hopes 7.1.2
I dug through the conversions involved (basically date_in and date_out).
AFAICS the only place where timezone could possibly get involved is that
DecodeDateTime attempts to derive a timezone for the given date/time.
It does this by calling mktime() (line 878 in datetime.c in current
Philip Warner [EMAIL PROTECTED] writes:
Do you have a alternate suggestion as to how to solve the problems it has
backing up the regression DB?
One possibility is to fix ALTER TABLE ADD COLUMN to maintain the same
column ordering in parents and children.
COPY with specified columns may in
On Mon, 30 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
FWIW, I've finished committing
Vadim Mikheev wrote:
There's a report of startup recovery failure in Japan.
Redo done but ...
Unfortunately I have no time today.
Please ask to start up with wal_debug = 1...
Isn't it very difficult for dbas to leave the
corrupted database as it is ?
ISTM we could hardly expect to
Corrupted or not, after a crash take a snapshot of the data tree
before firing it back up again. Doesn't take that much time
(especially with a netapp filer) and it allows for a virtually
unlimited number of attempts to solve the trouble or debug.
--
Rod Taylor
BarChord Entertainment Inc.
30 matches
Mail list logo
