"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Step 2 is to teach oper_select_candidate() about functions which
> accept unknown and _unknown that can be used as a last resort. We
> will allow coercions to type unknown and _unknown from any type to
> accomplish this but only in this specific case. W
"Marc G. Fournier" wrote:
>
> Mark (mlw) ... could you generate a listing of those variables you feel
> would need to be moved to a 'global structure' and post that to the list?
> That would at least give us a starting point, instead of both sides
> guessing at what is/would be involved ...
(1)
On Wed, 15 May 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Tue, 14 May 2002, Tom Lane wrote:
> >> I don't know whether we will bother with a 7.2.2 release ---
>
> > We could do up a 7.2.2 ...
>
> If ya wanna do one, no objection here. But let's see if we can't g
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 14 May 2002, Tom Lane wrote:
>> I don't know whether we will bother with a 7.2.2 release ---
> We could do up a 7.2.2 ...
If ya wanna do one, no objection here. But let's see if we can't get
some resolution of that command-tags-and-rules
On Tue, 14 May 2002, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > We have one patch for contrib/rtree_gist ( thanks Chris Hodgson for
> > spotting bug and test suite ). Should we submit patch for 7.2.2 and
> > 7.3 ?
>
> I don't know whether we will bother with a 7.2.2 release
On Tue, 14 May 2002, Myron Scott wrote:
>
>
> Tom Lane wrote:
>
> >
> >
> >With a little more intelligence in the manager of this table, this could
> >also solve my concern about pointer variables. Perhaps the entries
> >could include not just address/size but some type information. If the
> >m
I really like array iterators, and am interested in simplifying them
somewhat. Currently they required too many operator entries and
functions to be truely useful in the base.
Please fill in holes ;)
Ok, first step. The ability to create an operator that will work on a
vast number of data type
Thanks for the replies so far. I had been using cast(foo::text as
integer).
To clarify my question, does anyone know *why* I can't cast from varchar
to integer? Why should I have to cast to text first?
thanks
On Tuesday, May 14, 2002, at 04:47 PM, David Stanaway wrote:
> On Tue, 2002-05-1
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> We have one patch for contrib/rtree_gist ( thanks Chris Hodgson for
> spotting bug and test suite ). Should we submit patch for 7.2.2 and
> 7.3 ?
I don't know whether we will bother with a 7.2.2 release --- but if it's
a high-confidence bug fix, sure,
We have one patch for contrib/rtree_gist ( thanks Chris Hodgson for
spotting bug and test suite ). Should we submit patch for 7.2.2 and
7.3 ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
I've been working on merging the last few variable.c variables into GUC.
Here are some notes on what I'm planning to modify in GUC to make that
possible.
1. The variable.c routines have quite a few specialized error reports
(eg, rejecting intervals larger than months in SET TIME ZONE). While
we
Mark (mlw) ... could you generate a listing of those variables you feel
would need to be moved to a 'global structure' and post that to the list?
That would at least give us a starting point, instead of both sides
guessing at what is/would be involved ...
On Tue, 14 May 2002, Tom Lane wrote:
Tom Lane wrote:
>
>
>With a little more intelligence in the manager of this table, this could
>also solve my concern about pointer variables. Perhaps the entries
>could include not just address/size but some type information. If the
>manager knows "this variable is a pointer to a palloc'd str
Myron Scott <[EMAIL PROTECTED]> writes:
> Another suggestion might be to create a global hashtable that stores
> the size and pointer to global structures for each subsection. Each
> subsection can define its own globals structure and register them with
> the hashtable.
Hmm ... now *that* is an
Tom Lane wrote:
>Hannu Krosing <[EMAIL PROTECTED]> writes:
>
>>What would your opinion be of some hack with macros, like
>>
>
>>#if (Win32 or THREADED)
>>#define GLOBAL_ pg_globals.
>>#else
>>#define GLOBAL_
>>#endif
>>
>
>>and then use global variables as
>>
>
>>GLOBAL_globvar
>>
>
>>At least
Jan Wieck <[EMAIL PROTECTED]> writes:
> As I understood it the idea was to put the stuff, the
> backends inherit from the postmaster, into a centralized
> place, instead of having it spread out all over the place.
> What's wrong with that?
The main objection to it
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Although this config file stuff is small potatoes compared to the
> > Win32 stuff as recently discussed. And for that, please understand
> > that most of the developers here consider Win32 an inferior server
> > platform. In fact, Win3
Hannu Krosing <[EMAIL PROTECTED]> writes:
> What would your opinion be of some hack with macros, like
> #if (Win32 or THREADED)
> #define GLOBAL_ pg_globals.
> #else
> #define GLOBAL_
> #endif
> and then use global variables as
> GLOBAL_globvar
> At least in my opinion that would increase bot
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> tour=# explain analyze select * from tours where
>> ( operator_id in (2,3,4,5,7) and type_id = 4 ) or
>> ( operator_id = 8 and type_id = 3);
> Actually this plan looks very strange to me. One would expect it to only use
> type_idx twic
> I was expecting it to round off ... I think there's something wrong with
> the arithmetic in AdjustIntervalForTypmod.
Yup. I've now updated the lookup tables used for the calculation for the
--disable-integer-datetimes case. The --enable-integer-datetimes case
was already calculated correctly.
> > Are you sure that say, de_DE.utf8 locale produce meaningful results
> > for any other languages?
>
> there are often subtle differences, but upper() and lower() are much
> more likely to produce right results than collation order or date/money
> formats.
>
> in fact seem to be only 10 distin
On Tue, 2002-05-14 at 13:06, Oliver Elphick wrote:
> Current anon cvs does not generate GNUmakefile and src/Makefile.global.
> The same applies with both "make distclean" and a fresh checkout:
>
> olly@linda:.../pgsql$ ./configure --enable-locale --enable-recode
> --enable-multibyte --e
On Tue, 2002-05-14 at 09:52, Tatsuo Ishii wrote:
>
> Are you sure that say, de_DE.utf8 locale produce meaningful results
> for any other languages?
there are often subtle differences, but upper() and lower() are much
more likely to produce right results than collation order or date/money
formats
Current anon cvs does not generate GNUmakefile and src/Makefile.global.
The same applies with both "make distclean" and a fresh checkout:
olly@linda:.../pgsql$ ./configure --enable-locale --enable-recode
--enable-multibyte --enable-nls --with-pgport=9631 --with-CXX
--with-perl --wit
At 06:58 AM 5/14/02 +0100, Oliver Elphick wrote:
> > retarget a dump script to be reloaded in some other schema. If the
> > dump is cluttered with umpteen thousand copies of the schema name
> > that's going to be difficult.
>
>sed -e 's/ old_schema\./ new_schema./g'
>
>I don't think you should al
> > My Linux box does not have *.utf8 locales at all. Probably not so many
> > platforms have them up to now, I guess.
>
> What linux do you use ?
Kind of variant of RH6.2.
> At least newer Redhat Linuxen have them and I suspect that all newer
> glibc's are capable of using them.
I guess many
On Tue, 2002-05-14 at 03:29, Tatsuo Ishii wrote:
> > I think it is really not hard to do this for UTF-8. I don't have to know the
> > relation between the locale and the encoding. Look at this:
> > We can use the LC_CTYPE from pg_controldata or alternatively the LC_CTYPE
> > at server startup. For
On Tue, 2002-05-14 at 04:03, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Although this config file stuff is small potatoes compared to the
> > Win32 stuff as recently discussed. And for that, please understand
> > that most of the developers here consider Win32 an inferior server
28 matches
Mail list logo
