On Wed, 19 Mar 2003, Bruce Momjian wrote:
Here are a list of features that might be in 7.4. I know there are
several people involved in each of these items.
Tablespaces
I haven't seen any proposal for tablespaces recently. Is this something
that is actively being worked on?
Kris Jurka
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/interfaces/libpq -I../../../src/include -c -o
common.o common.c -MMD
common.c:184: conflicting types for `cancelConn'
common.h:30: previous declaration of `cancelConn'
make[3]: *** [common.o] Error 1
make[3]: Leaving
[Sorry for the delay, but the mail didn't reach me prior this morning.]
On Mon, Mar 17, 2003 at 09:09:22AM -0500, Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
gmake[4]: *** No rule to make target `../lib/typename.o', needed by `ecpg'. Stop.
Yeah, me too. I think the correct fix
On Wed, Mar 19, 2003 at 10:51:32PM -0500, Tom Lane wrote:
I've been amusing myself the last several evenings by working on a
reimplementation of the NUMERIC datatype, along the lines of previous
discussion (use base-1 digits instead of base-10 so that the number
of iterations of the inner
I just noticed that comparing a text to a varchar results in an index not
being used without a cast in some circumstances. Given that they have
identical internal representations (or so I believe), that seems a little odd.
Can anyone shed some light on this for me? I assume it has something to
Michael Meskes [EMAIL PROTECTED] writes:
But I wonder if we could arrange things so the Numeric stuff wents out
of the backend.
With suitable #define hacking you could perhaps take care of the code's
dependencies on palloc/pfree ... but elog is harder, and I don't see any
realistic way to
Philip Warner [EMAIL PROTECTED] writes:
I just noticed that comparing a text to a varchar results in an index not
being used without a cast in some circumstances. Given that they have
identical internal representations (or so I believe), that seems a little odd.
But they're not the same
On Thu, Mar 20, 2003 at 09:49:30AM -0500, Tom Lane wrote:
With suitable #define hacking you could perhaps take care of the code's
dependencies on palloc/pfree ... but elog is harder, and I don't see any
realistic way to handle the backend's function-call conventions as
opposed to conventions
I started working on date/timestamp in ecpg. So far I can read date
types from the DB and I can insert date into the DB. However there seems
to be a bug in converting timestamp to ascii or vice versa.
If anyone of you knows more about timestamp2tm etc. could you please
have a look at function
Michael Meskes [EMAIL PROTECTED] writes:
How about some wrapper frunctions in the backend that just call their
helper functions in the lib?
I'm not willing to do that for any very large number of functions; the
code clutter and runtime overhead would become significant.
I had some visions,
[ very off topic ]
Michael Meskes [EMAIL PROTECTED] writes:
I already have to manually sync code (preproc.y = gram.y) and don't
like the idea of having to do it with a lot more code.
I've been wondering for quite awhile if we couldn't find a way to avoid
manually duplicating the backend
On Thu, 2003-03-20 at 13:41, Barry Lind wrote:
However the proposed FE/BE protocol change to tell the client the
transaction state would allow the driver to detect this.
snip
Of these two limitations the first is more significant since users do
issue 'commit' statements directly
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think our SET functionality is easy to understand and use. I don't
see pushing it into the client as greatly improving things, and could
make things worse. If we can't get it right in the backend, how many
At 10:18 AM 20/03/2003 -0500, Tom Lane wrote:
I have been wondering whether we couldn't eliminate the datatype
distinction between text and varchar.
That would be great if done magically in the backend. If all text columns
were effectively wrapped in a Cast(X to text), life from a users PoV would
I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3195 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3196 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3197 -
fixing
2003-03-20 08:15:49
Does the new ALTER TABLE / CLUSTER ON syntax support the ONLY modifier - it
isn't documented if it is?? I guess it's not really relevant is it?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I just managed to break the CLUSTER ON patch:
test=# create table test (a int4 primary key, b int4 unique, c int4);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'test_pkey'
for table 'test'
NOTICE: CREATE TABLE / UNIQUE will create implicit index 'test_b_key' for
table 'test'
On Monday 10 March 2003 10:51 am, Tom Lane wrote:
* XML support? If we do anything, I'd want some extensible solution to
allowing multiple query-result output formats from the backend, not an
XML-specific hack. For one thing, that would allow the actual appearance
of any XML support to
This behaviour I find unusual:
usa=# explain analyze select user_id, plan_next from users_profiles where
plan_next = '2003-01-01';
QUERY PLAN
Surely the planner is aware that '2003-01-01'::date - interval '1 week' is
a
constant???
Actually, turns out that the planner was smarter than me I think. 2003-01-01
occurs very rarely in the system, but other dates occupy 1/7th of the table,
so it's not so easy to plan...
Chris
On Fri, 21 Mar 2003, Christopher Kings-Lynne wrote:
This behaviour I find unusual:
usa=# explain analyze select user_id, plan_next from users_profiles where
plan_next = '2003-01-01';
QUERY PLAN
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3195 -
fixing
Hmm. In 7.2.* I'd have said this was a known problem, but in 7.3.* it's
not. Want to dig into it? This is what I know about the 7.2
Gavin Sherry [EMAIL PROTECTED] writes:
I presume the type of plan_next is 'date'. Does casting '2003-01-01'::date
- interval '1 week' to date help?
Easier would be
'2003-01-01'::date - 7
which yields a date to start with. But yeah, date minus interval yields
a timestamp, which will not
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page
3195 -
fixing
Hmm. In 7.2.* I'd have said this was a known problem, but in 7.3.* it's
not. Want to dig into it? This is what I know about the 7.2
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
5. We have been having load and stability problems with our Postgres since
we released a massive upgrade to our website. We did actually have one time
when Postgres crashed and the whole server rebooted when we got a bunch of
these:
Mar 20
On Friday 21 Mar 2003 11:38 am, Christopher Kings-Lynne wrote:
phd=# select time(abstime(timestamp 'now')) from bookings;
ERROR: parser: parse error at or near abstime at character 13
phd=# select time(timestamp 'now') from bookings;
ERROR: parser: parse error at or near timestamp at
select time(abstime(timestamp 'now')) from bookings;
select time(timestamp 'now') from bookings;
First of all, thanks, it worked..
And What's so holy about if it is a function?
It's really old 7.1 syntax, not supported from 7.2+.
Basically it's because time can now have a precision.
Shridhar Daithankar[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
And What's so holy about if it is a function?
The problem is that TIME(n) is a datatype name, not a function call,
according to the SQL spec. Likewise for TIMESTAMP(n), INTERVAL(n),
NUMERIC(m,n), and maybe one or two other special
On Friday 21 Mar 2003 12:25 pm, Tom Lane wrote:
Shridhar Daithankar[EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
And What's so holy about if it is a function?
The problem is that TIME(n) is a datatype name, not a function call,
according to the SQL spec. Likewise for TIMESTAMP(n),
On Thu, Mar 20, 2003 at 01:40:44AM -0500, Tom Lane wrote:
There are indeed some first-cut provisions in the lock code for multiple
transactions owned by a backend, but it'd be dangerous to assume that
they are either correct or complete. The only case that's tested is for
VACUUM to hold a
Tom,
From the jdbc driver perspective I prefer the GUC variable approach,
but either can be used. Each has limitations.
In 7.2 and earlier jdbc code the driver handled the transaction
symantics by adding begin/commit/rollback in appropriate places. And
that code is still in the 7.3 driver
On Wed, 2003-03-19 at 20:32, Oleg Bartunov wrote:
On Wed, 19 Mar 2003, Alvaro Herrera wrote:
stringA||COALESCE(NULL, '')
we don't know in advance if it's NULL or not.
Right, that's the point of COALESCE: the first non-NULL argument is
returned -- so if the first argument to COALESCE
On Wed, 2003-03-19 at 20:32, Oleg Bartunov wrote:
On Wed, 19 Mar 2003, Alvaro Herrera wrote:
stringA||COALESCE(NULL, '')
we don't know in advance if it's NULL or not.
Right, that's the point of COALESCE: the first non-NULL argument is
returned -- so if the first argument to COALESCE
Bruce Momjian writes:
True, but GUC seems like the way to go, and we have per-user/db settings
for GUC.
But the required autocommit setting depends neither on the user nor the
database, it depends on the identity of the client application. That type
of granularity is not offered by GUC.
--
The specific case that Tom complained about wasn't even in the latest
documentation sources anymore. I think the patch should be reverted.
Bruce Momjian writes:
The following applied patch removes the section Tom thought wasn't
needed anymore.
Larry Rosenman writes:
I'm going to be looking into this, and was wondering what things people
were looking for as formatting types.
Personally, I would be looking for something that made sense. I.e., not
to_char.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
--On Thursday, March 20, 2003 17:09:18 +0100 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Larry Rosenman writes:
I'm going to be looking into this, and was wondering what things people
were looking for as formatting types.
Personally, I would be looking for something that made sense. I.e., not
Peter Eisentraut wrote:
Bruce Momjian writes:
True, but GUC seems like the way to go, and we have per-user/db settings
for GUC.
But the required autocommit setting depends neither on the user nor the
database, it depends on the identity of the client application. That type
of
OK, readded. Thanks.
---
Peter Eisentraut wrote:
The specific case that Tom complained about wasn't even in the latest
documentation sources anymore. I think the patch should be reverted.
Bruce Momjian writes:
39 matches
Mail list logo
