Tatsuo Ishii [EMAIL PROTECTED] writes:
It seems partial indexes with not null condition do not work:
What you created wasn't a partial index, it was a functional index.
Try something like
create index nonnullindex on accounts(bid) where bid is not null;
regards,
For me that seems to be the right way. I'm not sure if two oids are
the right solution but we need to store extra info in varlena
structure to support charset/collation anyway. In my understanding
TOAST has already done in similar way.
Other than charset/collation we also need
Tatsuo Ishii [EMAIL PROTECTED] writes:
It seems partial indexes with not null condition do not work:
What you created wasn't a partial index, it was a functional index.
Try something like
create index nonnullindex on accounts(bid) where bid is not null;
Sorry for the confusing and
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
and now we could add functions that work with this charset
CREATE FUNCTION bar (x VARCHAR(255) CHARACTER SET foo)
What we are saying is that we don't want to be able to do this?
Not sure we want to add above. Is it something defined
Tatsuo Ishii [EMAIL PROTECTED] writes:
Sorry for the confusing and foolish question. However still I wonder
why my expression(functional) index does not work.
You could likely have gotten it to match to a query like
SELECT ... WHERE (bid is not null) = true;
which would have the proper
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
and now we could add functions that work with this charset
CREATE FUNCTION bar (x VARCHAR(255) CHARACTER SET foo)
What we are saying is that we don't want to be able to do this?
Not sure we want to add above. Is it something
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
One of my boxes(emu) on the buildfarm fails to pass the float8
regressiontest:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emudt=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):
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 command?
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 charset.
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
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
-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
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
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
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
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
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:
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
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 so
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.
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)
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
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
-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
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 implemented in C
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 only sign
-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
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
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:
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
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,
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
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:
relocation
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)
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
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 that's not
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.h
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
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
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
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
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
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 to
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 of
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)
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
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
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
GUC variable
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 system
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 willing to
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; showing the list of
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
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
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 like
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
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 tablespace, such that all
TOAST tables would be put in the 'toastspace'. But I think the syntax is
ugly and would confuse
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:
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
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 postmaster might send
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 think
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
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'd
63 matches
Mail list logo