On Sat, 23 Oct 2004, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Dennis and I are hashing this out on IRC. The second option would be to
simply put SET SESSION AUTHORIZATION statements before each and every
statement in the pg_dump. This would make each statement atomic as
Dear Tom,
The obvious solution to this is to use Makefile.shlib all the time,
but there's a problem: Makefile.shlib is only designed to build a single
shlib per build subdirectory, and contrib/spi wants to build several.
I don't see any easy way to rejigger Makefile.shlib to support multiple
I found a nice page about daylight saving time that I want to share:
http://timeanddate.com/time/aboutdst.html
Here are some fun quotes from the page:
Sometimes DST is used for longer periods than just one summer, as in the
United States during World War II. From 3 Feb 1942 to 30 Sep 1945
Dennis Bjorklund [EMAIL PROTECTED] writes:
ps. This letter does not mean that I think it's bad to handle time zone
names, just that it's even more difficult then I first thought.
This is why we are being careful not to introduce any local changes into
the zic database. We can just drop in
Dennis,
Another observation is that SET SESSION AUTHORIZATION postgres; and RESET
SESSION AUTHORIZATION; would be the same when postgres is the superuser.
By not using the name of the superuser one get the benefit that one can
restore as another superuser (but see the part about acl's below).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I get an error while building 7.2.6 RPMS on Fedora Core 1.
# gcc --version
gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
# bison --version
bison (GNU Bison) 1.875
Devrim GUNDUZ [EMAIL PROTECTED] writes:
I get an error while building 7.2.6 RPMS on Fedora Core 1.
bison -y -d -p seg_yy segparse.y
segparse.y:101.7: syntax error, unexpected |
Not sure anyone still cares, but I've backpatched the 7.3 fix for this,
just in case we do make any further 7.2.*
With the patches Tom applied today, regarding the seg and cube modules
and get_progname(), cvs tip now fully (and for the first time) passes
all the buildfarm tests, including contrib installcheck.
cheers
andrew
---(end of broadcast)---
TIP 9: the
[EMAIL PROTECTED] (Ed L.) wrote:
Wow. First, thanks again for all your efforts, Jan. Second, I'm
disappointed to hear the slony author and lead developer is leaving
the slony leadership. When is that going to happen? And what does
that mean with respect to your future involvement in slony?
Would the version bump be a good time to fix the UNICODE encoding
misnomer in database creation and in the backend param status? I assume
it should be UTFx.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Will do a broad announce on Monday, but let me know if there are any
problems with it ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of
On Fri, Oct 22, 2004 at 03:35:49PM -0400, Jan Wieck wrote:
On 10/22/2004 2:50 PM, Simon Riggs wrote:
I've been using the ARC debug options to analyse memory usage on the
PostgreSQL 8.0 server. This is a precursor to more complex performance
analysis work on the OSDL test suite.
I've
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a column default expression, we:
(1) Accept the
On Sun, 24 Oct 2004, Neil Conway wrote:
(1) Accept the default's raw parsetree from the parser
(2) Convert it to a cooked parsetree via transformExpr()
(3) Add a coercion to the table's column type
Can't we save the cooked parsetree that we produced in #2?
One could even save the string as
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a
On Sun, 24 Oct 2004, Tom Lane wrote:
(1) Accept the default's raw parsetree from the parser
(2) Convert it to a cooked parsetree via transformExpr()
(3) Add a coercion to the table's column type
Can't we save the cooked parsetree that we produced in #2?
Not without an initdb (to have
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
And it
would
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
And it
would produce exactly the same result anyway, because the only way there
could be implicit coercion steps at the top of the expression is because
step 3 put them there.
Per your earlier comment: I am
I have read through this thread hoping that a solution would be found
but I see we are still poking. My ideas:
o Anything that works only for pg_restore and hence doesn't
work for ASCII dumps isn't an acceptable solution
o Creating the tablespaces before the dump is
Peter Eisentraut wrote:
Am Montag, 18. Oktober 2004 19:43 schrieb Tom Lane:
An alternative possibility is to stop pretending that pgport is agnostic
about whether it is in backend or frontend. This might mean some
duplication of code between src/port/ and src/backend/port/, but if
that's
At 12:38 PM 25/10/2004, Bruce Momjian wrote:
o Anything that works only for pg_restore and hence doesn't
work for ASCII dumps isn't an acceptable solution
Agree; but don't forget that an ascii dump is implemented almost
identically to pg_dump | pg_restore, so when I refer to
Mark,
I see nice graphs for each DBT3 query(for example,
http://developer.osdl.org/markw/dbt3-pgsql/42/q_time.png). It seems
they do not come with normal dbt3-1.4 kit. How did you get them?
Maybe you have slightly modified dbt3 kit?
--
Tatsuo Ishii
On 6 Feb, To: [EMAIL PROTECTED] wrote:
On
22 matches
Mail list logo
