Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
It'd be nice to have a predictable timezone choice made when there's a
tie. Perhaps we should order on timezone name in this case?
The Antarctica zones would tend to win with such a rule, which is
probably not what we want :-(. But certai
Oliver Jowett <[EMAIL PROTECTED]> writes:
> It'd be nice to have a predictable timezone choice made when there's a
> tie. Perhaps we should order on timezone name in this case?
The Antarctica zones would tend to win with such a rule, which is
probably not what we want :-(. But certainly we could
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Also I'm a bit nervous about that hardcoded 2004 start date for the scan
in pgtz.c -- that will presumably break if the timezone data files are
updated for post-2004 changes without a corresponding change to the scan
code.
Actually, that
Oliver Jowett wrote:
It seems like we should pass the original parameters from execution of
the DECLARE utility portal down through PortalRunUtility ->
ProcessUtility -> PerformCursorOpen, copy them into the newly created
portal's memory context, and pass the copies to PortalStart on the new
po
Tom Lane wrote:
Hm. The copying bit bothers me, and I guess after some thought it's
a semantic issue. If you've got
DECLARE c CURSOR FOR SELECT ... WHERE foo = $1;
FETCH 10 FROM c;
it's not very clear when the value of $1 should be supplied. With your
proposal the parameter value
I never really considered oracle's implementation of tablespaces when I
worked on tablespaces. The database default tablespace seems similar to
Oracle's SYSTEM tablespace. I'm not sure if they use a global tablespace
like we do.
My point was that Oracle has added a tablespace clause to the constra
I am working on the release notes now and should be done in 1-2 days.
I am a little concerned that we still have open items with scheduled
beta ten days away. My big three items are:
o Outstanding NT issues
o Outstanding PITR issues
o Missing documentation
Right now I
elein wrote:
I like inhertitance, but believe that the usefulness
of our implementation is limited and so the documentation
should focus on other areas.
+1
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister comm
I think you are reviving the inheritance wars.
Please do not cut out or dumb down anything that
accurately documents our features.
I think the section should remain, describing
exactly how they work and making it clear exactly
what parts inherited and what is not inherited.
That is where the most
David Fetter wrote:
> What do you all think?
Please discuss these matters on the pgsql-docs list.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
ht
On Thu, 2004-07-22 at 16:21, David Fetter wrote:
> Kind people,
>
> I am writing a document patch for the tutorials section, and would
> like to change the section on inheritance to reflect the fact that it
> is not currently being developed, and has known serious bugs in
> implementation.
I'd ca
I posted a message a couple weeks ago abou having a problem with a
user-defined C language aggregate and the ffunc being called multiple
times with the same state. I came up with a test case which shows the
problem with plpgsql functions. It occurs with an aggregate in an inner
query, when a
Kind people,
I am writing a document patch for the tutorials section, and would
like to change the section on inheritance to reflect the fact that it
is not currently being developed, and has known serious bugs in
implementation.
I'm thinking that I should either change that section to a warning
In preparation for 7.5 beta I am working on the release notes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Squar
Oliver Jowett <[EMAIL PROTECTED]> writes:
> It seems like we should pass the original parameters from execution of
> the DECLARE utility portal down through PortalRunUtility ->
> ProcessUtility -> PerformCursorOpen, copy them into the newly created
> portal's memory context, and pass the copies
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Also I'm a bit nervous about that hardcoded 2004 start date for the scan
> in pgtz.c -- that will presumably break if the timezone data files are
> updated for post-2004 changes without a corresponding change to the scan
> code.
Actually, that was int
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2004-07-22 at 01:44, Tom Lane wrote:
>> Agreed. Maybe it should be part of the bgwriter's idle loop, and
>> not directly associated with checkpoints at all.
> Yes, thats a more natural home, now bgwriter exists. But does it know
> when log files a
On Thu, 2004-07-22 at 12:49, Bruce Momjian wrote:
> OK, good, marked as done.
>
> ---
>
> Gavin Sherry wrote:
> > * Have psql show more information about sequences
> >
> > template1=# \d foo_seq
> > Sequence "public.foo_seq
Yep, wording updated:
* Have psql show current values for a sequence
---
Oliver Elphick wrote:
> On Thu, 2004-07-22 at 12:49, Bruce Momjian wrote:
> > OK, good, marked as done.
> >
> > ---
OK, good, marked as done.
---
Gavin Sherry wrote:
> * Have psql show more information about sequences
>
> template1=# \d foo_seq
> Sequence "public.foo_seq"
> Column | Type
> ---+-
> sequence_
> > DEBUG: TZ "Antarctica/McMurdo" scores 2534: at -442152000
> 1955-12-28 12:00:00 std versus 1955-12-29 00:00:00 std
> > DEBUG: TZ "Antarctica/South_Pole" scores 2534: at
> -442152000 1955-12-28 12:00:00 std versus 1955-12-29 00:00:00 std
> > DEBUG: TZ "Pacific/Auckland" gets max score 2600
Tom Lane wrote:
[... DECLARE with parameters failing ...]
Any chance of getting this fixed for 7.5?
I'm up to my keister in PITR and nested-xact issues and won't have time
to look at it soon. Do you want to take a look and see if you can find
where the ball is getting dropped?
Here's what I've fo
Oliver Jowett wrote:
The only timezones that get positive scores during startup are:
DEBUG: TZ "Antarctica/McMurdo" gets max score 2080
DEBUG: TZ "Antarctica/South_Pole" gets max score 2080
DEBUG: TZ "Pacific/Auckland" gets max score 2080
DEBUG: TZ "NZ" gets max score 2080
Either of "NZ" or "Pa
Tom Lane wrote:
But in any case, I've committed code that implements Oliver's idea.
Could folks take another swipe at it and see if it works well in their
local zones? Also, it'd still be interesting to see if we could #ifdef
out the matching on zone names for Windows and still get reasonable
resu
On Thu, 22 Jul 2004, Christopher Kings-Lynne wrote:
> >>Does anyone object to extending the grammar to allow this?
> >
> > Yes. This is horribly ugly, and I suspect that you cannot do it
> > without making TABLESPACE a fully-reserved word.
>
> I note that this seems to be the Oracle syntax:
>
> C
Since we stole tablespaces from Oracle, maybe we should make them work
the same?
I never really considered oracle's implementation of tablespaces when I
worked on tablespaces. The database default tablespace seems similar to
Oracle's SYSTEM tablespace. I'm not sure if they use a global tablespace
l
On Thu, 2004-07-22 at 01:44, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Yes, I agree, but the checkpointer isn't waking up often enough
> > currently to do this effectively. It's just randomly doing it.
>
> Agreed. Maybe it should be part of the bgwriter's idle loop, and
> not
Does anyone object to extending the grammar to allow this?
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
This suggests a slightly different oracle syntax. I guess the word
'index' is optional.
http://www.jlcomp.demon.co.uk/ch_18
Does anyone object to extending the grammar to allow this?
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
I note that this seems to be the Oracle syntax:
CONSTRAINT PK_Stock PRIMARY KEY (Company) USING INDEX TABLESPACE
Appl_Indexes
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
No, I've already done it and it works just fine. What is your
suggestion then? Just assume the name of the index it will get?
Also, I realised that the pg_get_serial_sequence() does
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Does anyone object to extending the grammar to allow this?
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
regards, tom lane
---
Does anyone object to extending the grammar to allow this?
ALTER TABLE test ADD PRIMARY KEY (a) TABLESPACE foo;
ALTER TABLE test ADD UNIQUE (a) TABLESPACE foo;
CREATE TABLE test (a INTEGER PRIMARY KEY TABLESPACE foo);
CREATE TABLE test (a INTEGER UNIQUE TABLESPACE foo);
This is needed since we can
32 matches
Mail list logo
