On Fri, Nov 7, 2008 at 3:35 AM, Ron Mayer [EMAIL PROTECTED] wrote:
I think I updated the web site and git now, and
'P-00-01' is now accepted. It might be useful if
someone double checked my reading of the spec, tho.
Hi Ron,
I've tested out your latest revision and read the spec more
On Fri, 2008-10-31 at 16:03 +0200, Peter Eisentraut wrote:
Here is an implementation of distinct types, known from SQL99 and
beyond. They are like domains, except that they don't have defaults or
constraints and they do not allow implicit casting to their base type.
The latter aspect is what
Updated version attached, this time without the compiler warning.
Sorry for the sloppy work.
...Robert
Index: doc/src/sgml/array.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/array.sgml,v
retrieving revision 1.67
diff -c
Hi,
* We approximate never vacuumed by has relpages = 0, which
* means this will also fire on genuinely empty relations. Not
* great, but fortunately that's a seldom-seen case in the real
* world, and it shouldn't degrade the quality of the
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Eh, Tom has a point. If we build module loading for 8.5, we shouldn't
change the functionality in the interim for 8.4. Annoying as it is.
The main reason I'm concerned about it is that when we do modules
(which I certainly hope
On Thu, 2008-10-09 at 19:06 +0900, ITAGAKI Takahiro wrote:
Thanks for your reviewing, Alex.
I applied your comments to my patch.
I made a few changes:
1. fixed some minor issues with auto_explain.sgml so that it would build
(and renamed to auto-explain.sgml to match other files)
2. added
On Wed, 2008-11-05 at 23:17 +0900, Fujii Masao wrote:
Authentication
---
As pointed out at another thread, for authentication, I defined the database
only for replication (named walsender tentatively). walsender database is
not pseudo but created by initdb like postgres
Bernd Helmle a écrit :
--On Donnerstag, November 06, 2008 11:35:54 +0100 Guillaume Lelarge
[EMAIL PROTECTED] wrote:
Guillaume Lelarge a écrit :
v4 patch attached.
v5 patch attached.
Thanks Guillaume.
Maybe this is nit-picking, but i see that you have to rmdir() an
existing empty
On 11/6/08, Jaime Casanova [EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 9:24 AM, Matteo Beccati [EMAIL PROTECTED] wrote:
Hi,
Attached test shows a regression in analyze command.
Expected rows in an empty table is 2140 even after an ANALYZE is
executed
Doesn't seem to be a regression to
On Thu, 2008-10-09 at 19:06 +0900, ITAGAKI Takahiro wrote:
Thanks for your reviewing, Alex.
I applied your comments to my patch.
Hi,
This seems like a very useful feature, and it works nicely.
Initial comments:
1. Please sync with HEAD. There was a change made on Oct. 31st that
affects this
I updated the patch set of SE-PostgreSQL (revision 1197).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1197.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1197.patch
[3/6]
After looking at additional heap and b-tree index placed in pg_bitmapindex
namespace...
Additional heap contains unique values and page's number with offset number in
bitmap index, b-tree index contains tuples with the same values and ItemPointer
to heap's row. So, heap is an unnecessary step
Guillaume Lelarge [EMAIL PROTECTED] writes:
Bernd Helmle a écrit :
Maybe this is nit-picking, but i see that you have to rmdir() an
existing empty tablespace directory to use copydir() afterwards. Maybe
we can teach copydir() to error out when trying to mkdir() an existing
directory only when
--On Freitag, November 07, 2008 09:36:32 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd, did you have any further comments? If not I'll get started on
this patch.
No, i think this patch is ready for a committer then.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing
Brendan Jurd wrote:
On Fri, Nov 7, 2008 at 3:35 AM, Ron Mayer [EMAIL PROTECTED] wrote:
I think I updated the web site and git now, and
'P-00-01' is now accepted. It might be useful if
someone double checked my reading of the spec, tho.
I've tested out your latest revision and read the
On Fri, 2008-11-07 at 18:20 +0900, KaiGai Kohei wrote:
I updated the patch set of SE-PostgreSQL (revision 1197).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1197.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1197.patch
This patch ensures that the PD_PAGE_FULL bit is restored after replaying
a heap_update WAL record. I think this must have been overlooked on the
HOT patch.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7
So I'm looking at the patch for ALTER DATABASE SET TABLESPACE, and
wondering about what happens if there's a system crash midway through.
The answer doesn't look too good: if the deletion pass has started,
your database is hosed.
I think we can fix this along the following lines:
1. Copy
Tom Lane wrote:
That is, that's true as long as the filesystem copy in fact pushed
everything to disk. copydir() does an fsync() on each file it copies,
so I think we have done as much as we can to protect the data being
copied, but I wonder if anyone feels it's too dangerous?
Do we need to
Jeff Davis wrote:
It still needs to be merged with HEAD.
ExecutorRun function signature has changed to return void. Other than that
it seems OK. I'll add a few additional notes:
One thing that I noticed was that tab completion queries are also explained
if explain.log_min_duration is set to
Martin Pihlak [EMAIL PROTECTED] writes:
- Do we need to support copyObject/equal for the fdw/server/user mapping
parse nodes?
Yes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Alvaro Herrera [EMAIL PROTECTED] writes:
Do we need to fsync the directory itself? My fsync(2) manpage says
Calling fsync() does not necessarily ensure that the entry in the
directory
containing the file has also reached disk. For that an explicit
fsync() on a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Do we need to fsync the directory itself? My fsync(2) manpage says
Calling fsync() does not necessarily ensure that the entry in
the directory
containing the file has also reached disk. For that an explicit
On Fri, 2008-11-07 at 18:03 +0200, Martin Pihlak wrote:
One thing that I noticed was that tab completion queries are also explained
if explain.log_min_duration is set to zero. Actually this also applies to
psql \dX commands. Don't know if this is deliberate or not. Example:
It's logged at the
On Fri, 2008-11-07 at 09:11 -0800, David E. Wheeler wrote:
On Nov 6, 2008, at 11:51 PM, Jeff Davis wrote:
It needs documentation, and I included a quick patch for that (if
that's
helpful).
You mis-spelled cast as case.
Thanks. Updated diff attached.
Regards,
Jeff Davis
Could you please put more comments on the index build procedure?
I guess it strongly relies on the fact the block number increases as tuples
are returned from heap scan, doesn't it? However, thanks to synchronized
scans the order of tuples could be a little bit different.
I found no evidence of
Attached is next revision of the connection manager, this is now nearly
feature complete -- the syntax is there, privileges are implemented.
Should apply cleanly to HEAD and pass regression. There are some usage
examples at: http://wiki.postgresql.org/wiki/SqlMedConnectionManager#Examples
Some
On Sat, 2008-11-01 at 16:38 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
(1) Can you compare a literal of the base type?
No, unless you create additional casts or operators.
(2) Can you explicitly cast to
On Fri, 2008-11-07 at 09:39 -0800, Jeff Davis wrote:
On Sat, 2008-11-01 at 16:38 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
(1) Can you compare a literal of the base type?
No, unless you create
Additional heap contains unique values and page's number with offset
number in bitmap index, b-tree index contains tuples with the same values
and ItemPointer to heap's row. So, heap is an unnecessary step - b-tree
index should store ItemPointer to the bitmap index directly.
B-tree points to
Josh Berkus wrote:
Tom,
I don't recall that having been proposed, and I don't think it's really
a good idea. We intentionally put those SETs in, not that long ago.
I haven't been able to find any reasoning on any list why those SETs
where a good idea. Bruce put them in, but
Jeff Davis wrote:
postgres=# create type mytype as int;
CREATE DOMAIN
Is that really the return message we want?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Nov 5, 2008, at 12:34 PM, Kenneth Marshall wrote:
I am using the anonymous CVS repository, it returns the following
information in pg_catalog.pg_settings:
What is lc_collate set to?
% show lc_collate;
FWIW, I just ran the tests myself and all passed, with and without the
patch (using
Simon Riggs wrote:
Some initial thoughts based upon reading the Wiki. I've not been
involved in things up to now, so if this dredges up old discussions,
well, these are my thoughts.
I want SEPostgreSQL, but I'd like it to work without needing to be a
compile time option so people can just
Guillaume Lelarge [EMAIL PROTECTED] writes:
v5 patch attached.
Applied with corrections, mostly ensuring crash-safety and arranging
to clean up if the initial copy phase fails (think out-of-disk-space).
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Thu, 2008-11-06 at 10:20 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
On a recent test the last command of the last test has failed:
DROP TABLESPACE testspace;
ERROR: tablespace testspace is not empty
Maybe it is failing due to files that are
On Nov 3, 2008, at 11:15 AM, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 10:52 AM, Alvaro Herrera wrote:
Maybe we should link to this page in the pg_typeof() description.
Also,
perhaps this page needs more examples.
Yes, both of those would help a lot, I
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
v5 patch attached.
Applied with corrections, mostly ensuring crash-safety and arranging
to clean up if the initial copy phase fails (think out-of-disk-space).
Thanks for your tips and corrections. I'll go read the diff to
Jeff Davis [EMAIL PROTECTED] writes:
On Sat, 2008-11-01 at 16:38 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
There is an implicit AS ASSIGNMENT cast between the base type and the
distinct
type in each direction.
Hmm ... so out-of-the-box, a distinct type would have
On Fri, Nov 07, 2008 at 10:15:17AM -0800, David E. Wheeler wrote:
On Nov 5, 2008, at 12:34 PM, Kenneth Marshall wrote:
I am using the anonymous CVS repository, it returns the following
information in pg_catalog.pg_settings:
What is lc_collate set to?
% show lc_collate;
FWIW, I just ran
On Nov 7, 2008, at 10:43 AM, Kenneth Marshall wrote:
Thank you for the pointers. lc_collate is set to en_US.UTF-8.
Huh. Same as for me.
I re-initdb the database with the --no-locale option and then the
tests passed successfully. Thank you for the reminder that the
regression tests need to
The patch for the citext tests applied to module cleanly
and the patched files resulted in a clean make installcheck
run for the citext module. My previous problem was the result
of not testing with a C locale database. This patch is ready
to be applied.
Regards,
Ken Marshall
--
Sent via
Andrew Dunstan [EMAIL PROTECTED] writes:
Jeff Davis wrote:
postgres=# create type mytype as int;
CREATE DOMAIN
Is that really the return message we want?
That's an artifact of the fact that the patch tries to piggyback on
the DOMAIN infrastructure instead of implementing its own statement
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Hmm, oh I see another problem here -- the bit is not restored when
replayed heap_update's WAL record. I'm now wondering what other bits
are set without much care about correctly restoring them during replay.
I'm now wondering whether it'd be
Kenneth Marshall [EMAIL PROTECTED] writes:
Thank you for the pointers. lc_collate is set to en_US.UTF-8. I
re-initdb the database with the --no-locale option and then the
tests passed successfully. Thank you for the reminder that the
regression tests need to run against a C locale database.
On Nov 7, 2008, at 11:15 AM, Tom Lane wrote:
In a quick test on a Fedora box, citext is the only core or contrib
test
that fails in en_US. (This is true in HEAD, even without having
applied
the proposed patch.) It would be good to clean that up.
Huh. There must be something different
David E. Wheeler [EMAIL PROTECTED] writes:
Huh. There must be something different about the collation for en_US
on Fedora than there is for darwin (what I'm using), because for me,
as I said, all tests pass.
Yeah, Darwin seems to just use ASCII sort order in en_US (couldn't say
about its
On Nov 7, 2008, at 11:50 AM, Tom Lane wrote:
This is why I like TAP.
And how would TAP reduce the number of expected results?
TAP doesn't compare output to expected output files. It's simply a
test result output stream. A separate program then harnesses that
output, looks at what passed
On Fri, Nov 07, 2008 at 03:56:25PM +0300, Teodor Sigaev wrote:
After looking at additional heap and b-tree index placed in
pg_bitmapindex namespace...
Additional heap contains unique values and page's number with offset
number in bitmap index, b-tree index contains tuples with the same
Bruce Momjian wrote:
Thanks for the review, Magnus. I have adjusted the patch to use the
same mutex every time the counter is accessed, and adjusted the
pqsecure_destroy() call to properly decrement in the right place.
Also, I renamed the libpq global destroy function to be clearer
(the
Foreign Key deletions could be handled correctly if you treat them as
updates. If we have the following example
TableA
security_context=y value=2 fk=1
TableB
security_context=x value=1
TableA refers to TableB. Context x cannot see context y.
So if somebody with context x tries to
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 7, 2008, at 11:50 AM, Tom Lane wrote:
And how would TAP reduce the number of expected results?
TAP doesn't compare output to expected output files. It's simply a
test result output stream. A separate program then harnesses that
output,
Heikki Linnakangas napsal(a):
Tom Lane wrote:
I think we can have a notion of pre-upgrade maintenance, but it would
have to be integrated into normal operations. For instance, if
conversion to 8.4 requires extra free space, we'd make late releases
of 8.3.x not only be able to force that to
Benedek László wrote:
Hi,
The patch contains the following things:
- pg_dump and pg_dumpall accepts the --role=rolename parameter, and
sends a SET ROLE command on their connections
Minor comment -- I think you need to quote the role name in the SET
command. Otherwise roles with funny
Jeff Davis wrote:
It's logged at the LOG level, just like log_min_duration_statement, and
seems to have the same behavior. What do you think it should do
differently?
There was actually a patch to disable the psql notices, but there were
some concerns and I think it was removed:
Tom Lane napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
Adding catalog columns seems rather complicated, and not back-patchable.
Agreed, we'd not be able to make them retroactively appear in 8.3.
I imagined that you would have just a single cluster-wide variable, a
GUC perhaps,
On Nov 7, 2008, at 12:12 PM, Tom Lane wrote:
... and you have very limited visibility into what went wrong, if
anything goes wrong. That's not real attractive for the buildfarm
environment. I like being able to see the actual query output.
It depends on how you write it - you can add a lot
Michael Meskes [EMAIL PROTECTED] writes:
... What still needs to be done is beautifying the script (I don't like
all those static declarations) and removing the remaining changes to gram.y.
There are only two left (variable handling on quite some places and
prepared_name twice).
Adding a new
On Fri, 2008-11-07 at 22:23 +0200, Martin Pihlak wrote:
Patch is at:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01274.php
and seems to get rid of the annoying messages. If there aren't any
major issues with it, I think it should be re-added.
I still don't understand why this
Martin Pihlak [EMAIL PROTECTED] writes:
There was actually a patch to disable the psql notices, but there were
some concerns and I think it was removed:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01264.php
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01752.php
Patch
Tom Lane napsal(a):
I think we can have a notion of pre-upgrade maintenance, but it would
have to be integrated into normal operations. For instance, if
conversion to 8.4 requires extra free space, we'd make late releases
of 8.3.x not only be able to force that to occur, but also tweak the
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
* Add a format serial number column to pg_class, and probably also
pg_database. Rather like the frozenxid columns, this would have the
semantics that all pages in a relation or database are known to have at
least the specified
On Fri, 2008-11-07 at 15:12 -0500, Robert Haas wrote:
Foreign Key deletions could be handled correctly if you treat them as
updates. If we have the following example
TableA
security_context=y value=2 fk=1
TableB
security_context=x value=1
TableA refers to TableB. Context x
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see system items. See the archives for much more
discussion on the issue.
Simon Riggs wrote:
Minor bug fix for pg_stop_backup() to prevent it waiting longer than
necessary in certain circumstances.
As far as I can tell, this patch needs to be applied to HEAD, 8.3 and
8.2 (when xlog switch was implemented), and in fact it applies cleanly
to them. Please confirm.
--
The low-privilege user isn't elevating the label. If the tuple was
visible by multiple labels it was already elevated. All I am suggesting
is the system remove the one it can see, leaving the other ones intact.
This makes the row appear to be deleted by the lower privileged user,
whereas in
Greg Sabino Mullane wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see system items. See the archives for
Peter Eisentraut [EMAIL PROTECTED] writes:
+ | TABLE table_ref
BTW, this seems to accept *way* more than is intended by the spec.
I think a closer approximation would be TABLE relation_expr.
You could even make a case for TABLE qualified_name, which is
what the letter of the
On Fri, Nov 07, 2008 at 01:50:18PM +, Simon Riggs wrote:
How will unique indexes work? Do you implicitly add security context as
last column on every unique index, or does the uniqueness violation only
occurs within security contexts, or does the uniqueness violation tested
against all
Simon Riggs [EMAIL PROTECTED] writes:
Any system with more than 32,000 security contexts is going to be
unmanageable and probably therefore insecure...
Perhaps, but it's doubtful that such a restriction will actually save
any space after you consider the alignment behavior. I'd go with an
Oid.
Simon Riggs wrote:
So if somebody with context x tries to delete value1 from TableB, they
will be refused because of a row they cannot see. In this case the
correct action is to update the tuple in TableB so it now has a
security_context = y. The user with x cannot see it and can be
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 11:15 AM, Tom Lane wrote:
Feel free to send in a docs patch ...
Well, I wasn't sure of the appropriate place to add examples to
datatype.sgml. But this patch would certainly make the output of
pg_typeof() much clearer to
On Nov 7, 2008, at 2:55 PM, Tom Lane wrote:
Well, I wasn't sure of the appropriate place to add examples to
datatype.sgml. But this patch would certainly make the output of
pg_typeof() much clearer to newbies like me.
Applied with some further editorialization.
Thanks!
David
--
Sent via
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
3. the help.c patch breaks alignment of the help output. I think the
best way to fix it would be to change [PATTERN] into something shorter
like [PAT] and add a mention to that in the first line, something like
I'd rather stick
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 7, 2008, at 11:15 AM, Tom Lane wrote:
My inclination is to remove the XML-dependent citext tests, which don't
seem especially useful, and then we can have whatever variants we need
for locales. citext locale behavior seems much more
Hi,
As I have not found yet an elegant solution to deal with the DROP
CASCADE issue, here is a simpler patch that handles temp tables that are
dropped at commit time. This is a good first step and we will try to
elaborate further to support ON COMMIT DELETE ROWS.
I have also added a
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
3. the help.c patch breaks alignment of the help output. I think the
best way to fix it would be to change [PATTERN] into something shorter
like [PAT] and add a mention to that in the first line, something
Alvaro Herrera wrote:
Bruce Momjian wrote:
Thanks for the review, Magnus. I have adjusted the patch to use the
same mutex every time the counter is accessed, and adjusted the
pqsecure_destroy() call to properly decrement in the right place.
Also, I renamed the libpq global destroy
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd rather stick with [PATTERN]. Can't we just add more spaces to keep
all the descriptions aligned?
Yes, but it shortens the available space for all the texts (which could
cause some of them to become two lines, but I didn't check)
On Nov 7, 2008, at 3:18 PM, Tom Lane wrote:
Agreed, but I admit to being mystified as to why things would be
sorting any differently on darwin vs. Fedora. I kept everything in
ASCII, on your advice, to keep from having to deal with crap like
this.
Patch applied with this adjustment.
On Tue, 2008-09-30 at 23:52 +0100, Simon Riggs wrote:
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
If using synchronous
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 7, 2008, at 3:18 PM, Tom Lane wrote:
Patch applied with this adjustment.
Great. So does it now pass all tests on Fedora?
Yeah, I checked with both C and en_US.utf8 locales. It's likely that
these two cases will cover them all, though I was
On Fri, 2008-11-07 at 13:19 -0500, Bruce Momjian wrote:
The security context on each row could be an optional column present
only if HEAP_HASSECURITYCONTEXT is set (0x0010 see htup.h), just
like
OIDs. Use a specific datatype rather than TEXT. That datatype could
be
an identifier to
Alvaro Herrera [EMAIL PROTECTED] writes:
3. the help.c patch breaks alignment of the help output. I think the
best way to fix it would be to change [PATTERN] into something shorter
like [PAT] and add a mention to that in the first line, something like
I'd rather stick with [PATTERN]. Can't
Ron Mayer [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
The changes to the documentation all look good. I did notice one
final typo that I think was introduced in the latest version.
doc/src/sgml/datatype.sgml:2270 has Nonstandardrd instead of
Nonstandard.
Just checked in a fix to that
Tom Lane wrote:
I've started reviewing this patch for commit, and I find myself a bit
disturbed by its compatibility properties. The SQL_STANDARD output
style is simply ambiguous: what is meant by
-1 1:00:00
? What you get from that will depend on the intervalstyle setting at
the
Ron Mayer wrote:
Tom Lane wrote:
*pg_dump had better force Postgres mode*. We can certainly do that with
a couple more lines added to the patch, but it's a bit troublesome that
we are boxed into using a nonstandard dump-data format until forever.
Ok. I see that is the concern..
Rather than
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've started reviewing this patch for commit, and I find myself a bit
disturbed by its compatibility properties. The SQL_STANDARD output
style is simply ambiguous: what is meant by
-1 1:00:00
? What you get from that will depend on the
Ron Mayer [EMAIL PROTECTED] writes:
Rather than forcing Postgres mode; couldn't it put a
set intervalstyle = [whatever the current interval style is]
in the dump file?
This would work for loading into a PG = 8.4 server, and fail miserably
for loading into pre-8.4 servers. Even though we don't
Tom Lane wrote:
ISO date format is read the same regardless of recipient's datestyle,
so pg_dump solves this by forcing the dump to be made in ISO style.
The corresponding solution for intervals will be to dump in POSTGRES
style, not SQL_STANDARD style, which seems a bit unfortunate.
[reading
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Rather than forcing Postgres mode; couldn't it put a
set intervalstyle = [whatever the current interval style is]
in the dump file?
This would work for loading into a PG = 8.4 server, and fail miserably
for loading into pre-8.4 servers.
91 matches
Mail list logo
