On Sun, 2004-10-31 at 05:32, Tom Lane wrote:
> The behaviors you mention were written at different times by different
> people, and mostly have nothing to do with schemas per se. I agree that
> some more consistency would probably be good. Do you have a specific
> proposal?
Sure, I just thought
I've looked into storing charset/collation in the string values. This
means that we change varchar/text/BpChar to be structures that have a
charset oid field and a collation oid field, the rest of the Datum is the
string data.
Coercability I think one don't need to put in the Datum and it can be
s
Where are we on this patch?
---
Zeugswetter Andreas DAZ SD wrote:
>
> > o fix shared memory on Win2k terminal server
> >
> > We might be able to just mark this as not supported.
>
> I have attached a patch that I
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We have this open item:
> > Win32
> > o Handle "lost signals" on backend startup (eg. shutdown,
> > config file changes, etc); signals are SIG_DFL on startup
>
> > The problem here is that the postmast
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We have this open item:
> Win32
> o Handle "lost signals" on backend startup (eg. shutdown,
> config file changes, etc); signals are SIG_DFL on startup
> The problem here is that the postmaster might send signals to a
>
OK, TODO updated:
* Add a GUC variable to control the tablespace for temporary
objects
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Gavin Sherry wrote:
> >> I'm not sure about TOAST
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Gavin Sherry wrote:
>> I'm not sure about TOAST however. I considered the idea of adding
>> something to CREATE TABLE like TOASTSPACE , such that all
>> TOAST tables would be put in the 'toastspace'. But I think the syntax is
>> ugly and would confuse man
On Sat, 2004-10-30 at 00:50, Tom Lane wrote:
> (1) What are the protection requirements for this variable?
I think it can be USERSET -- most commands let the user specify a
tablespace explicitly, and this is basically just another way of doing
that. The user executing the query will need CREATE pr
On Mon, 2004-11-01 at 07:51, Tom Lane wrote:
> I looked at this a bit more and found that on Linux, the dynamic
> loader is documented to search "rpath" before LD_LIBRARY_PATH;
> so had we not specified an rpath when building the psql executable,
> pg_regress would have worked as intended. Sounds
On Sun, 2004-10-31 at 10:49, Tom Lane wrote:
> Er ... can't you just keep it in pkglibdir and refer to it via $libdir?
> Given that 8.0 now supports relocatable installations, I'd think it best
> to avoid hardwiring any paths at compile time.
Hmm..
I think it would be best to keep Python [extensi
We have this open item:
Win32
o Handle "lost signals" on backend startup (eg. shutdown,
config file changes, etc); signals are SIG_DFL on startup
The problem here is that the postmaster might send signals to a
child before the signal handlers are install
On Mon, Nov 01, 2004 at 12:49:47AM +0100, Gaetano Mendola wrote:
> Josh Berkus wrote:
> >Neil,
> >
> >
> >>pg_functions might be useful, but what would pg_users offer that pg_user
> >>does not already do?
> >
> >
> >Show a list of groups that the user belongs to? Same thing with
> >pg_groups; sho
Added to open items:
* Add a GUC variable to control temporary and TOAST tablespace usage
---
Gavin Sherry wrote:
> On Sun, 31 Oct 2004, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > I wrote:
> > > > I'd be wil
Gavin Sherry wrote:
> > One downside that came up yesterday in a discussion is that once shemas
> > don't have default tablespaces we can't easily have default tablespaces
> > for toast and temporary table system schemas. Now we can't actually do
> > that now anyway because they are created by the
On Sun, 31 Oct 2004, Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > I'd be willing to jump this way if we can work out the
> > > default-tablespace inconsistencies that Bruce has on the open items
> > > list.
> >
> > After further thought it seems to me that using a default_tablespace
>
Josh Berkus wrote:
Neil,
pg_functions might be useful, but what would pg_users offer that pg_user
does not already do?
Show a list of groups that the user belongs to? Same thing with pg_groups;
showing the list of users in the group.
A pg_sequences view might also be handy.
Yes. Anything el
Tom Lane wrote:
> I wrote:
> > I'd be willing to jump this way if we can work out the
> > default-tablespace inconsistencies that Bruce has on the open items
> > list.
>
> After further thought it seems to me that using a default_tablespace
> GUC variable doesn't eliminate all the open issues. In
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > $(PTHREAD_H_WIN32) is a dependency of libpq and therefore we had to copy
> > it into Makefile.shlib when we are compiling from that file rather than
> > libpq/Makefile. libpq/Makefile has:
>
> > all: $(PTHREAD_H_WIN32) $(top_buildd
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
It's time for the 6 monthly discussion of the failure of the horology
tests during DST changeover.
This will go away whenever we fix the interval datatype to distinguish
'1 day' from '24 hours'. In the meantime, it reminds us o
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It's time for the 6 monthly discussion of the failure of the horology
> tests during DST changeover.
This will go away whenever we fix the interval datatype to distinguish
'1 day' from '24 hours'. In the meantime, it reminds us of the work we
need t
I noticed today that we have once again managed to break PG's handling
of ambiguous timestamps during a DST backwards transition. For example,
in EST5EDT time zone, '2004-10-31 01:30:00' is ambiguous. The intention
of the code for a long time has been to treat such times as being local
standard t
It's time for the 6 monthly discussion of the failure of the horology
tests during DST changeover.
I'd like to find a way to avoid this, so we don't get spurious buildfarm
failures for 2 or 3 days every six months. ISTM the first thing is to
isolate the tests that are sensitive to it into a se
James William Pye wrote:
If this is the stance that the group has, that is fine. For now, I will
continue my shameful practice of parsing up pg_config --version and
defining the components for use in my source. (;
FWIW, here's what I've been using in PL/R for a while now:
/* working with postgres 7
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Oh, so you are using yesterday's libpq.so shared library ;-)
I am not sure there is any way around that except to go ahead and
install today's libpq. pg_regress can't do much more than set
LD_LIBRARY_PATH, and evide
David Fetter wrote:
On Sat, Oct 30, 2004 at 11:55:48PM +0200, Markus Bertheau wrote:
CREATE OR REPLACE FUNCTION array_to_column (ANYARRAY)
You want to see that function distributed with PostgreSQL? It would
probably have to be implemented in C then, because PL/pgSQL-support
has to be explicitly "e
Bruce Momjian <[EMAIL PROTECTED]> writes:
> $(PTHREAD_H_WIN32) is a dependency of libpq and therefore we had to copy
> it into Makefile.shlib when we are compiling from that file rather than
> libpq/Makefile. libpq/Makefile has:
> all: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Oh, so you are using yesterday's libpq.so shared library ;-)
>>
>> I am not sure there is any way around that except to go ahead and
>> install today's libpq. pg_regress can't do much more than set
>> LD_LIBRARY_PATH, and evidently th
I wrote:
> I'd be willing to jump this way if we can work out the
> default-tablespace inconsistencies that Bruce has on the open items
> list.
After further thought it seems to me that using a default_tablespace
GUC variable doesn't eliminate all the open issues. In particular
it is no help for
Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
> > [ Makefile.shlib contains ]
>
> > all-lib: all-static-lib all-shared-lib
>
> > all-static-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h
> > lib$(NAME).a
>
> > all-shared-lib: $(PTHREAD_H_WIN32)
Tom Lane wrote:
> Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> >> Try removing the "2>/dev/null" bit so that you can see if any error
> >> messages come out from psql.
>
> > Ok, we have a detailed error now:
>
> > /home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
On Sun, 31 Oct 2004, Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The Linux [ext2] fsync man page says:
"It does not necessarily ensure that the entry in the directory
containing the file has also reached disk. For that an explicit fsync on
the file descriptor of the directory is
On Mon, 1 Nov 2004, Oliver Jowett wrote:
Heikki Linnakangas wrote:
The Linux fsync man page says:
"It does not necessarily ensure that the entry in the directory containing
the file has also reached disk. For that an explicit fsync on the file
descriptor of the directory is also needed."
AFAIK,
James William Pye <[EMAIL PROTECTED]> writes:
>> At compile time, you should be checking the specific feature you care
>> about,
> Well, for one of my uses, it is not a feature check. My PL loads a
> Python extension module whose path is dependent on the major and minor
> version of the PostgreSQL
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
>> Try removing the "2>/dev/null" bit so that you can see if any error
>> messages come out from psql.
> Ok, we have a detailed error now:
> /home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
> relocation error:
> /home/
On Sun, 2004-10-31 at 08:02, Tom Lane wrote:
> This has been proposed and rejected before, mainly on the grounds that
> it would encourage bad programming practices.
I admit that I am probably practicing this bad programming at few places
in my source, and shame on me for it. I have hoped to tight
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Sun, 31 Oct 2004, Tom Lane wrote:
LOG: unexpected EOF on client connection
Hmm, that seems to be the only sign of trouble, which I guess means we
have to conclude the problem is on the client side not the server side.
The part of the pg_regress
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
>>> pg_regress: could not set database default locales
>>
>> What shows up in the postmaster log file?
> You mean src/test/regress/log/postmaster.log, right?
> Actually not that much:
> LOG: unexpected EOF on client connection
Hmm, that seems to be the
On Sat, Oct 30, 2004 at 11:55:48PM +0200, Markus Bertheau wrote:
> В Сбт, 30.10.2004, в 21:54, David Fetter пишет:
> > Kind people,
>
> > CREATE OR REPLACE FUNCTION array_to_column (ANYARRAY)
>
> You want to see that function distributed with PostgreSQL? It would
> probably have to be implemente
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Sun, 31 Oct 2004, Tom Lane wrote:
pg_regress: could not set database default locales
What shows up in the postmaster log file?
You mean src/test/regress/log/postmaster.log, right?
Actually not that much:
LOG: database system was shut down at 200
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> pg_regress: could not set database default locales
What shows up in the postmaster log file?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
In general we expect the filesystem to take care of its own metadata.
Run ext3 in journaling mode, or something like that.
(It occurs to me that the admin guide really ought to have a few words
about recommended and non-recommended filesystems ...)
Well I am not their admin, but I don't suggest
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> [ Makefile.shlib contains ]
> all-lib: all-static-lib all-shared-lib
> all-static-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h
> lib$(NAME).a
> all-shared-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_confi
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The Linux [ext2] fsync man page says:
"It does not necessarily ensure that the entry in the directory
containing the file has also reached disk. For that an explicit fsync on
the file descriptor of the directory is also needed."
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The Linux [ext2] fsync man page says:
> "It does not necessarily ensure that the entry in the directory
> containing the file has also reached disk. For that an explicit fsync on
> the file descriptor of the directory is also needed."
This seems s
James William Pye <[EMAIL PROTECTED]> writes:
> Would it be possible to get something along the lines of the attached
> patch in 8? (major,minor,patch,state version defines)
This has been proposed and rejected before, mainly on the grounds that
it would encourage bad programming practices.
At com
I have some problems when adjusting PL/Java to use PGXS in its
makefiles. Aside from the Win32 problem I asked about earlier, I also
have problems using the MODULE_big. When used, it brings in the
Makefile.shlib and attempts to use the target all-lib. That target is
defined as:
all-lib: al
Greets,
Would it be possible to get something along the lines of the attached
patch in 8? (major,minor,patch,state version defines)
(I tried making them shell vars and giving it to AC_INIT, but it seemed
to want a literal, so...)
Yes, I know there are other ways to get and define this informatio
Heikki Linnakangas wrote:
The Linux fsync man page says:
"It does not necessarily ensure that the entry in the directory
containing the file has also reached disk. For that an explicit fsync on
the file descriptor of the directory is also needed."
AFAIK, we don't care about it at the moment. The
Hi all,
I am getting a regression failure on float8 (and float4) when running on Debian Sarge
on Alpha (gcc 3.3.4). Postgres
is a HEAD checkout from yesterday.
test=# select version();
version
The Linux fsync man page says:
"It does not necessarily ensure that the entry in the directory
containing the file has also reached disk. For that an explicit fsync on
the file descriptor of the directory is also needed."
AFAIK, we don't care about it at the moment. The actual behaviour depends
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm getting this error on two different servers, one if them is the server
that I build PostgreSQL from CVS daily, the other one is a fresh one (used
to double-check the error)
Two servers have LANG="en_US.UTF-8". They are RHEL 3.0 Update 3 with
> On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
>
> > I don't understand your point. Today we already use one length()
> > function for any charsets as Tom has already pointed out.
>
> We have one length function that inside do different things depending on
> the charset. If you want to add a charset
> > I wonder what is the intention to allow such that syntax. It seems
> > it's just useless since we could make a function bar() which accepts
> > any charsets.
>
> One could override the behaviour of functions by adding a charset and a
> adding new definition of an old function name for that cha
On Sat, 30 Oct 2004 16:45:22 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Wed, Oct 27, 2004 at 09:29:21PM -0400, Tom Lane wrote:
> >> Wouldn't it be better to just stay in TBLOCK_STARTED state, as if the
> >> COMMIT were just some random utility com
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
> I don't understand your point. Today we already use one length()
> function for any charsets as Tom has already pointed out.
We have one length function that inside do different things depending on
the charset. If you want to add a charset and implement
One of my boxes(emu) on the buildfarm fails to pass the float8
regressiontest:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emu&dt=2004-10-31%2003:35:02
the interesting thing is that spoonbill (slightly older
OpenBSD-current/Sparc64) passes this test(but fails contribcheck later on):
http:
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
> I wonder what is the intention to allow such that syntax. It seems
> it's just useless since we could make a function bar() which accepts
> any charsets.
One could override the behaviour of functions by adding a charset and a
adding new definition of an
57 matches
Mail list logo
