Re: [BUGS] HELP! BUG? pg_dump mucks up grant/revoke
Dear All, With regard to the rather old bug report about pg_dump outputting ACL commands on views before the views have been created (see http://archives.postgresql.org/pgsql-general/2001-07/msg01051.php), I take it this bug is fixed in the latest release? More importantly, is there anywhere I can download the latest version of pg_dump on it's own, as updrading one component to fix this bug will be a whole lot easier than upgrading our whole installation. (I am using PostgreSQL 7.2.2 on SuSE [Linux version 2.4.19-64GB-SMP ([EMAIL PROTECTED]) (gcc version 3.2.2)]) If someone could point me at the relevant parts of the source, I could build it myself, but an RPM would be ideal. Any help much appreciated, sorry if this is not quite the right list, Misha Gale -- Misha Gale [EMAIL PROTECTED] -- http://www.fastmail.fm - I mean, what is it about a decent email service? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [GENERAL] Convert TimeStamp to Date
Yep ... looks like it got broken in 7.3.
7.2.4 works fine, but 7.3 (and CVS tip) doesn't.
This is because in 7.2, timestamp_date () and timestamptz_date () do the
same thing -
convert the time to Julian date and then subtruct the offset for Y2K,
and both work.
In 7.3 (and 7.4) timestamptz_date () is still doing that (and select
'1999-12-31 00:00:01'::timestamptz::date still works),
*but* timestamp_date() is changed for some reason to just divide the
timestamp by the number of microseconds per day, that is obviously wrong
for the case when ts is negative (before 2000) because integer division
(unlike floor ()) truncates towards zero...
I'd send the patch... but just thought I would better be done by someone
who knows the reason why that function had changed to begin with...
Dima
Claudio Lapidus wrote:
template1=# insert into t values ('1993-08-10 17:48:41');
INSERT 16980 1
So we are talking about August 10th, right?
template1=# select f1, date(f1), f1::date, cast(f1 as date) from t;
f1 |date| f1 | f1
-+++
1993-08-10 17:48:41 | 1993-08-11 | 1993-08-11 | 1993-08-11
(1 row)
Here all casts give Aug. 11th, same as on my 7.3.2 (tested right now). This
is one day *more* than expected, not 'the previous date' as the original
poster said. Perhaps some sort of rounding here?
cl.
---(end of broadcast)---
TIP 8: explain analyze is your friend
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] [GENERAL] Convert TimeStamp to Date
Dmitry Tkach <[EMAIL PROTECTED]> writes: > In 7.3 (and 7.4) timestamptz_date () is still doing that (and select > '1999-12-31 00:00:01'::timestamptz::date still works), > *but* timestamp_date() is changed for some reason to just divide the > timestamp by the number of microseconds per day, that is obviously wrong > for the case when ts is negative (before 2000) because integer division > (unlike floor ()) truncates towards zero... Good catch. It looks like Tom Lockhart changed this routine when he was adding the int64-timestamp option. He probably had a momentary brain fade about the direction of rounding needed :-( I've changed it back to doing things the 7.2 way in CVS tip. This will be in 7.3.4 unless Marc already wrapped the tarball, which I don't think he did. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Small problem in contrib/dbase/dbf2pg.c
Thomas, would you send me a context diff (diff -c) of the change and I
will get into 7.4. Thanks.
---
Thomas Behr wrote:
> Your name : Thomas Behr
> Your email address : [EMAIL PROTECTED]
> System Configuration
> -
> Architecture (example: Intel Pentium) : ALL
> Operating System (example: Linux 2.0.26 ELF) : ALL
> PostgreSQL version (example: PostgreSQL-7.3.3): PostgreSQL-7.3.3
> Compiler used (example: gcc 2.95.2) : WorkShop Compilers 5.0 98/12/15
> C 5.0
> Please enter a FULL description of your problem:
>
> dbf2pg - Insert xBase-style .dbf-files into a PostgreSQL-table
> There is an option "-s oldname=newname", which changes the old field name of
> the dbf-file to the newname in PostgeSQL. If the length of the new name is 0,
> the field is skiped. If you want to skip the first field of the dbf-file,
> you get the wildest error-messages from the backend.
> dbf2pg load the dbf-file via "COPY tablename FROM STDIN". If you skip the
> first field, it is an \t to much in STDIN.
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> --
> dbf2pg -s first_field_name=,other_fieldname=,reserved_fieldname=new_fieldname
> -c -d testdb -t testtable -h dbhost -U testuser -F IBM437 -T ISO-8859-1 -vv
> test.dbf
>
> If you know how this problem might be fixed, list the solution below:
> -
>
> 440 /* build line and submit */
> 441 result = dbf_get_record(dbh, fields, i);
> 442 if (result == DBF_VALID)
> 443 {
> 444 query[0] = '\0';
> 445 for (h = 0; h < dbh->db_nfields; h++)
> 446 {
> 447 if (!strlen(fields[h].db_name))
> 448 continue;
> 449
> 450 if (h != 0) /* not for the first field! */
> 451 strcat(query, "\t");/* COPY statement field
> 452 * separator */
>
>
>
> A fix could be an counter j=0, which increments only, if a field is imported
> (IF (strlen(fields[h].db_name)> 0) j++. And only if j > 1 (if an other field is
> imported) the \t is printed.
>
> ...
> int j;
> ...
>
> if (result == DBF_VALID)
> {
> query[0] = '\0';
> j = 0;
> for (h = 0; h < dbh->db_nfields; h++)
> {
> if (!strlen(fields[h].db_name))
> {
> continue;
> }
> else
> {
> j++;
> }
>
> if (j > 1) /* not for the first field! */
> strcat(query, "\t");/* COPY statement field
> * separator */
>
>
> An other small bug in the README:
> -s start
> Specify the first record-number in the xBase-file
> we will insert.
> should be
> -e start
> Specify the first record-number in the xBase-file
> we will insert.
>
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
