> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
> Sent: 30 September 2002 21:11
> To: Dave Page
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?)
>
>
> Dave Page writes:
>
> > Can someone who knows
On Mon, Sep 30, 2002 at 06:31:15PM -0400, Tom Lane wrote:
> The middle part of that boils down (as of today) to
>
> regression=# select to_date('402002', 'WW');
> to_date
>
> 2002-10-01
> (1 row)
>
> and Oct 1 (tomorrow) is Tuesday. As to why it picks that day to
> represent
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The patch below 'fixes' this (and possibly breaks everything else). I
>> haven't tested it rigorously and it *just* special cases group by
>> clauses with functions in them.
Surely this cure is worse than the disease.
The general problem is that we do
> > Thanks to a user query (handle: lltd, IRC) I came across a bug in the
> > planner. The query was:
> >
> > ---
> > select o1.timestamp::date as date, count(*), (select sum(oi.price) from
> > "order" o2, "order_item" oi where oi.order_id = o2.id and
> > o2.timestamp::date = o1.timestamp::date
Here is an email from Gavin showing a problem with subqueries and casts
causing errors when they shouldn't.
---
Gavin Sherry wrote:
> Hi Bruce,
>
> Thanks to a user query (handle: lltd, IRC) I came across a bug in the
> pl
OK, 7.2.3 is all branded and ready to go. HISTORY/release.sgml shows:
---
Release Notes
Release 7.2.3
Release date: 2002-10-01
This has a varie
On Mon, Sep 30, 2002 at 06:49:34PM -0400, Tom Lane wrote:
| The other issue is what
| to_date(...,'WW') should do to produce a date representing a week
| number. Shouldn't it always produce the first date of that week?
| If not, what other conventions make sense?
IMHO, it should choose the "
On Tue, 2002-10-01 at 03:49, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Tue, 2002-10-01 at 03:31, Tom Lane wrote:
> >> I notice that 2001-12-31 is considered part of the first week of 2002,
> >> which is also pretty surprising:
>
> > There are at least 3 different ways to
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Tue, 2002-10-01 at 03:31, Tom Lane wrote:
>> I notice that 2001-12-31 is considered part of the first week of 2002,
>> which is also pretty surprising:
> There are at least 3 different ways to start week numbering:
> ...
> I suspect it depends on loc
On Tue, 2002-10-01 at 03:31, Tom Lane wrote:
> Offhand this seems kinda inconsistent to me --- I'd expect
>
> regression=# select extract(week from date '2002-09-30');
> date_part
> ---
> 40
> (1 row)
>
> to produce 39, not 40, on the grounds that the first day of Week 40
> is
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see how we can be compliant if SQL92 says:
> The time of evaluation of the during the
> execution of the SQL-statement is implementation-dependent.
> It says it has to be "during the SQL statement", or is SQL statement
> also ambiguo
Rod Taylor <[EMAIL PROTECTED]> writes:
> select to_char(
>to_date(
> CAST(extract(week from CURRENT_TIMESTAMP) as text)
> || CAST(extract(year from CURRENT_TIMESTAMP) as text)
> , 'WW')
>, 'FMDay, D');
> to_char
>
> Tuesday, 3
> (1 row)
> Not that it
select to_char(
to_date(
CAST(extract(week from CURRENT_TIMESTAMP) as text)
|| CAST(extract(year from CURRENT_TIMESTAMP) as text)
, 'WW')
, 'FMDay, D');
to_char
Tuesday, 3
(1 row)
Not that it matters for me at the moment (I care that it's in the week
Zeugswetter Andreas SB SD writes:
> Attached is a patch to fix the mb linking problems on AIX. As a nice side effect
> it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so
> (all shlibs that are not postmaster loadable modules).
Can you explain the method behind your patch
Bruce Momjian writes:
> Peter, the author is questioning why his Makefile changes were wrong.
> Would you elaborate?
Because we rely on the built-in library lookup functionality instead of
hardcoding the full file name.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end
On Mon, Sep 30, 2002 at 11:18:27AM -0400, Tom Lane wrote:
> use 7.3beta1 has had). On the third hand, the patch only does something
> if mktime() has already failed, so it's hard to see how it could make
> life worse even if it's buggy.
On those grounds alone, it seems worth putting in. As you
I'm done making back-patches for 7.2.3. Over to you, Bruce ...
attached is the REL7_2_STABLE branch history since 7.2.2.
regards, tom lane
2002-09-30 16:57 tgl
* src/backend/utils/adt/: date.c, datetime.c (REL7_2_STABLE):
Back-patch fixes to work around
On Mon, 30 Sep 2002 15:29:07 -0400, Mike Mascari <[EMAIL PROTECTED]>
wrote:
> I'm wondering how the others handle multiple
>references in CURRENT_TIMESTAMP in a single stored
>procedure/function invocation.
MSSQL 7 seems to evaluate CURRENT_TIMESTAMP for each statement,
Interbase 6 once per pro
Bruce Momjian wrote:
> Hannu Krosing wrote:
>
>>It can be, as "during the SQL statement" can mean either the single
>>statement inside the PL/SQL function (SELECT CURRENT_TIMESTAMP INTO
>>time1 FROM DUAL;) or the whole invocation of the Pl/SQL funtion (the /
>>command in Mikes sample, i believe)
Hannu Krosing wrote:
> On Tue, 2002-10-01 at 01:10, Bruce Momjian wrote:
> >
> > > Given what Tom has posted regarding the standard, I think Oracle
> > > is wrong. I'm wondering how the others handle multiple
> > > references in CURRENT_TIMESTAMP in a single stored
> > > procedure/function inv
On Tue, 2002-10-01 at 01:10, Bruce Momjian wrote:
>
> > Given what Tom has posted regarding the standard, I think Oracle
> > is wrong. I'm wondering how the others handle multiple
> > references in CURRENT_TIMESTAMP in a single stored
> > procedure/function invocation. It seems to me that the
I am starting to see Tom's issue here. If you have a PL/pgSQL function
that does:
> >>DECLARE
> >>BEGIN
> >> SELECT CURRENT_TIMESTAMP INTO time1 FROM DUAL;
> >> SELECT CURRENT_TIMESTAMP INTO time2 FROM DUAL;
> >>END;
You would want those two to be the same because they are in the same
functi
Dave Page writes:
> Can someone who knows make better than I (which is probably the vast
> majority of you!) knock up a makefile so the driver will build
> standalone on *nix systems please? There should be no dependencies on
> any of the rest of the code - certainly there isn't for the Win32 bui
Tom Lane writes:
> Why is that better than the other direction?
It isn't. Let's just keep committing to the head and merge it into 7.3
later.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at
Bruce Momjian wrote:
> It is not clear to me; is this its own transaction or a function call?
>
That looks like an anonymous PL/SQL procedure to me. Another
question might be, given:
"more than one reference to one or more s, then all such references are effectively evaluated
simultaneously"
It is not clear to me; is this its own transaction or a function call?
---
Dan Langille wrote:
> And just for another opinion, which supports the first.
>
> >From now, unless you indicate otherwise, I'll only report tests
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I get on postgresql.org on a previously checked out CVS:
> $ cvs -q -d :pserver:[EMAIL PROTECTED]:/cvsroot checkout -P pgsql
> cvs checkout: move away pgsql/contrib/earthdistance/Makefile; it is in the way
> C pgsql/contrib/earthdistance/Makefile
> [etc
Greg Copeland <[EMAIL PROTECTED]> writes:
> Should an advisory be issued for production sites to not perform a
> vacuum full with a notice that a bug fix will be coming shortly?
People seem to be misunderstanding the bug. Whether your vacuum is FULL
or not (or VERBOSE or not, or ANALYZE or not)
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 30 Sep 2002, Bruce Momjian wrote:
>> Yes. We need a decision now because I don't know which branch to touch.
>> Marc, I need your feedback on these ideas. There is discussion about
>> fixing earthdistance. Perhaps we fix that and remove t
Marc G. Fournier wrote:
> On Mon, 30 Sep 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > >
> > > can you create a project on gborg under 'server modules' for this?
> >
> > Uh, I don't see the logic in moving earthdistance out of /contrib. It
> > uses /cube, which is in contrib. I d
OK, I just received this answer from an Oracle 9 tester. It shows
CURRENT_TIMESTAMP changing during the transaction. Thanks, Dan.
Dan, it wasn't clear if this was in a transaction or not. Does Oracle
have autocommit off by default so you are always in a transaction?
-
Nothing against including it from me ...
On Mon, 30 Sep 2002, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > On Fri, Sep 27, 2002 at 08:30:38PM -0400, Bruce Momjian wrote:
> >> OK, we need a decision on whether we are going to do a 7.2,3 or just
> >> have it in beta3. If it
On Mon, 30 Sep 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian writes:
> > >> I don't think we want a branch for 7.4 yet. We still have lots of open
> > >> issues and the branch will require double-patching.
> >
> > > Merge the ch
On Mon, 30 Sep 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> >
> > can you create a project on gborg under 'server modules' for this?
>
> Uh, I don't see the logic in moving earthdistance out of /contrib. It
> uses /cube, which is in contrib. I didn't think we were moving loadable
> mo
Tom Lane wrote:
> Any votes on whether to fix that or leave it alone in 7.2.3? I need
> some input in the next few hours ...
Including it sounds like a good idea.
'Yes' from me.
:)
Regards and best wishes,
Justin Clift
> regards, tom lane
>
>
Should an advisory be issued for production sites to not perform a
vacuum full with a notice that a bug fix will be coming shortly?
Greg
On Sat, 2002-09-28 at 13:45, Justin Clift wrote:
> Bruce Momjian wrote:
> >
> > I have seen no discussion on whether to go ahead with a 7.2.3 to add
> > sev
Tom Lane wrote:
> One thing I am undecided about: I am more than half tempted to put in
> the fix that makes us able to cope with mktime's broken-before-1970
> behavior in recent glibc versions (e.g., Red Hat 7.3). This seems like
> a good idea considering that other Linux distros will surely be
Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > On Fri, Sep 27, 2002 at 08:30:38PM -0400, Bruce Momjian wrote:
> >> OK, we need a decision on whether we are going to do a 7.2,3 or just
> >> have it in beta3. If it is in 7.2.3, I would not mention it in the
> >> beta3 release not
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Fri, Sep 27, 2002 at 08:30:38PM -0400, Bruce Momjian wrote:
>> OK, we need a decision on whether we are going to do a 7.2,3 or just
>> have it in beta3. If it is in 7.2.3, I would not mention it in the
>> beta3 release notes.
> If there won't be a
Justin Clift wrote:
> Bruce Momjian wrote:
> >
> > OK, we need a decision on whether we are going to do a 7.2,3 or just
> > have it in beta3. If it is in 7.2.3, I would not mention it in the
> > beta3 release notes.
>
> We definitely should have a 7.2.3. If we can release a 7.2.2 to fix
> bugs
CURRENT_TIMESTAMP returns the time of the transaction start, not the
statement start. We are currently discussing on hackers whether this is
correct or not. We don't currently allow you to access the statement
start time. Sorry.
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> I don't think we want a branch for 7.4 yet. We still have lots of open
> >> issues and the branch will require double-patching.
>
> > Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
Bruce Momjian wrote:
>
> OK, we need a decision on whether we are going to do a 7.2,3 or just
> have it in beta3. If it is in 7.2.3, I would not mention it in the
> beta3 release notes.
We definitely should have a 7.2.3. If we can release a 7.2.2 to fix
bugs and a security flaw, then we should
On Fri, Sep 27, 2002 at 08:30:38PM -0400, Bruce Momjian wrote:
>
> OK, we need a decision on whether we are going to do a 7.2,3 or just
> have it in beta3. If it is in 7.2.3, I would not mention it in the
> beta3 release notes.
If there won't be any 7.2.3, could a note be put up on the website
Just wanted to pipe in here. I am still very interested in tablespaces ( I have many
database systems that are over
500GB and growing) and am willing to port my tablespace patch to 7.4. I have
everything (but only tested here) working
in 7.2 but the patch was not accepted. I didn't see a grea
> > > > and mb conversions (pg_ascii2mic and pg_mic2ascii not
> > > > found in the postmaster and not included from elsewhere)
> >
> > shared libs on AIX need to be able to resolve all symbols at linkage time.
> > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres
> > executa
46 matches
Mail list logo
