Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
... The only thing that doesn't work
right now is a function that returns RECORD (not SETOF) since the rsinfo
in this case is NULL. Can you shed some light on that?
What's the test case exactly?
thhal=# create function javates
Tom Lane wrote:
You could do worse than to back-port get_call_result_type() into your
older branches and just leave out the code for the OUT parameter case.
Great advice! I went ahead and did just that. Now PL/Java handles
IN/INOUT/OUT parameters correctly with 8.1 and it handles functions
ret
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> ... The only thing that doesn't work
> right now is a function that returns RECORD (not SETOF) since the rsinfo
> in this case is NULL. Can you shed some light on that?
What's the test case exactly?
regards, tom lane
---
Given all the problems with unwanted recoding I've seen, I think such an
encoding should be the default instead of unchecked-8-bits SQL_ASCII :-(
I agree, but that would be a nightmare of backwards compaitibility :D
Chris
---(end of broadcast)---
TIP
On Wed, Apr 13, 2005 at 10:10:32AM +0800, Christopher Kings-Lynne wrote:
> Can I put in a request for a '7 bit ascii' encoding for PostgreSQL :)
Given all the problems with unwanted recoding I've seen, I think such an
encoding should be the default instead of unchecked-8-bits SQL_ASCII :-(
--
A
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> template1=# cluster pg_attribute_relid_attnam_index on pg_attribute;
> ERROR: "pg_attribute" is a system catalog
That error has nothing to do with any risk of reassigning OIDs. The
issue is whether we can change the index's relfilenode or not --- the
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> So some changing-oid operations like vacuum full, reindex, etc will not
>> affect these system catalogs?
> Is it possible to cluster system tables?
No, and yes. CLUSTER, REINDEX, and similar things change the
relfilenode, not the relation OI
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes
> Is it possible to cluster system tables?
>
Ooops, I guess I mixed two concepts - oid and relfilenode. Those operations
change relfilenode but not oids. I don't think we could cluster system
tables.
template1=# select oid, relfilenode from pg
On Wed, Apr 13, 2005 at 09:54:28AM +0800, Christopher Kings-Lynne wrote:
> >So some changing-oid operations like vacuum full, reindex, etc will not
> >affect these system catalogs?
>
> Is it possible to cluster system tables?
No. And then, some catalogs are only allowed to be reindexed in place.
Is PostgreSQL supposed to enforce a LATIN1/ISO-8859-1 encoding if that's
the database encoding?
AFAIK, there are no illegal characters in 8859-1, except \0 which we
do reject.
Hmmm...
It turns out I was confused by the developer who reported this issue.
Basically they have a requirement that they
So some changing-oid operations like vacuum full, reindex, etc will not
affect these system catalogs?
Is it possible to cluster system tables?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
"Tom Lane" <[EMAIL PROTECTED]> writes
> While thinking about the use of hand-assigned OIDs for pg_proc and
> pg_operator, it occurred to me to wonder why we don't have hand-assigned
> OIDs for all system catalogs and indexes. Currently, most of the time
> that the C code wants to reference a speci
While thinking about the use of hand-assigned OIDs for pg_proc and
pg_operator, it occurred to me to wonder why we don't have hand-assigned
OIDs for all system catalogs and indexes. Currently, most of the time
that the C code wants to reference a specific catalog or index, it has
to reference it b
Currently there are three mechanisms for assigning OIDs to system
objects during initdb:
1. Manual assignment of OIDs in the include/catalog/*.h files. (We need
to do this for objects that are cross-referenced in other DATA entries
or that we have or might want #define macros for. So, though it'
On Tue, Apr 12, 2005 at 11:58:43AM -0400, [EMAIL PROTECTED] wrote:
> Hello...
>
> I'm in rather dire-straits here. I just mistakenly deleted all the
> entries in a table and I need to recover them. I'm told that there's
> something I can do along the lines of "hacking up a PG to show deleted
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Apr 12, 2005 at 05:04:03PM -, Andrew - Supernews wrote:
>> Checking the OID might be sufficient if it were possible to make the OID
>> counter restart at some value known to be greater than any datlastsysoid,
>> rather than restarting at Boot
Hello...
I'm in rather dire-straits here. I just mistakenly deleted all the
entries in a table and I need to recover them. I'm told that there's
something I can do along the lines of "hacking up a PG to show deleted
'tuples'" ...
Any help would be VERY much appreciated.
--Joshua
---
On Tue, Apr 12, 2005 at 05:04:03PM -, Andrew - Supernews wrote:
> On 2005-04-12, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >> Well perhaps there is an even better solution?
> >
> > What about the simple one of having a bool "pg_cast.castissystem"
> > column, or something similar?
>
> Checkin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What about the simple one of having a bool "pg_cast.castissystem"
> column, or something similar?
This one is sounding pretty good to me, though I'd be inclined to call
it "castisbuiltin" or some such.
regards, tom lane
---
On 2005-04-12, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>> Well perhaps there is an even better solution?
>
> What about the simple one of having a bool "pg_cast.castissystem"
> column, or something similar?
Checking the OID might be sufficient if it were possible to make the OID
counter restart
On Tue, 2005-04-12 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Could anybody comment on whether the current tests appropriately cover
> > the correctness of the external sorting algorithms?
>
> It's highly unlikely that the regression tests stress external sorts
>
On Tue, Apr 12, 2005 at 06:38:41PM +0200, Michael Paesold wrote:
> Alvaro Herrera wrote:
>
> >On Tue, Apr 12, 2005 at 08:39:09AM +0200, Michael Paesold wrote:
> >>Tom Lane wrote:
> >
> >>>The other possible solution that comes to mind is to invent the
> >>>notion that a cast has a specific owner (
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> But yes, schema-qualifying casts seems weird:
> '123'::someschema.user_type
> Is that even accepted by the grammar?
Yes, but it'd be taken as a qualification on the type name not the cast
per se. Offhand I'm not sure where we could even put a schema
Alvaro Herrera wrote:
On Tue, Apr 12, 2005 at 08:39:09AM +0200, Michael Paesold wrote:
Tom Lane wrote:
>The other possible solution that comes to mind is to invent the notion
>that a cast has a specific owner (which arguably it should have anyway)
>and then say that "system casts" are those whose
On Tue, Apr 12, 2005 at 08:39:09AM +0200, Michael Paesold wrote:
> Tom Lane wrote:
> >The other possible solution that comes to mind is to invent the notion
> >that a cast has a specific owner (which arguably it should have anyway)
> >and then say that "system casts" are those whose owner is the o
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> PL/Java will not handle the RECORD case gracefully at present I'm
> afraid. The 8.0 compatible version will need some improvements. How is
> the TupleDesc obtained in case of RECORD in 8.0.x? Is it the same in 7.4?
In 8.0 and before I think you have
Tom Lane wrote:
If you use that, it will look just the same as the existing situation
where you are declared to return RECORD and someone calls you with
a column name/type list in FROM. Whether you want any additional
smarts is up to you.
- The TupleDesc returned by the get_call_result_type() i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Incidentally, thanks to Jim Buttafuoco, we now have a Windows box
> (goose) on the buildfarm building every day, so when things look screwy
> you can check there to see if other people are having the same problem.
Indeed, I checked the buildfarm statu
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Try "make distclean" and a full rebuild.
>>
> Much better :-) Thanks!
Always the first thing to try if you get a weird failure after CVS update.
(Personally I never even try to do a partial rebuild after updating;
I can overlap reco
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I get the following error message when I try to do an initdb with CVS
HEAD on a Win32 platform:
creating configuration files ... ok
creating template1 database in data-head/base/1 ... FATAL: access
method "btree" does not su
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> My compile failure was due to the change of proargtypes from Oid* to an
> oidvector. I initially thought that had something to do with OUT parameters.
No, not directly. The diffs needed for that are pretty simple though.
> - I assume that by using t
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I get the following error message when I try to do an initdb with CVS
HEAD on a Win32 platform:
creating configuration files ... ok
creating template1 database in data-head/base/1 ... FATAL: access
method "btree" does not sup
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I get the following error message when I try to do an initdb with CVS
> HEAD on a Win32 platform:
> creating configuration files ... ok
> creating template1 database in data-head/base/1 ... FATAL: access
> method "btree" does not support unique inde
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I've read about changes in CVS head needed to accomodate OUT parameters.
I tried to compile PL/Java and it fails (of course). Is there any brief
text somewhere that highligts the changes that where made and explains
how the new stuff wo
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I've read about changes in CVS head needed to accomodate OUT parameters.
> I tried to compile PL/Java and it fails (of course). Is there any brief
> text somewhere that highligts the changes that where made and explains
> how the new stuff works? It'
Simon Riggs <[EMAIL PROTECTED]> writes:
> Could anybody comment on whether the current tests appropriately cover
> the correctness of the external sorting algorithms?
It's highly unlikely that the regression tests stress external sorts
much, or that anyone would hold still for making them run long
I get the following error message when I try to do an initdb with CVS
HEAD on a Win32 platform:
creating configuration files ... ok
creating template1 database in data-head/base/1 ... FATAL: access
method "btree" does not support unique indexes
child process was terminated by signal 1
Regards,
Hi
in the function ExecChooseHashTableSize()
(~/src/backend/executor/nodeHash.c)
are determined the bytes of the hash table. The correspondent code is:
/*
* Target in-memory hashtablesize in SortMem kilobytes
*/
hash_table_bytes = SortMem *1024L
(~/src/include/miscadmin.h)
extern DLLIMPORT in
Tom Lane said:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Is PostgreSQL supposed to enforce a LATIN1/ISO-8859-1 encoding if
>> that's the database encoding?
>
> AFAIK, there are no illegal characters in 8859-1, except \0 which we do
> reject.
>
Perhaps Chris is confusing ISO/IEC 885
I've read about changes in CVS head needed to accomodate OUT parameters.
I tried to compile PL/Java and it fails (of course). Is there any brief
text somewhere that highligts the changes that where made and explains
how the new stuff works? It's hard and somewhat time consuming to try to
deduct
PostgreSQL uses two different sorting algorithms, qsort and the external
sorting method in tuplesort.c. There are some possible improvements in
external sorting, so I'd like to check on the solidity of the testing
mechanisms.
Whether external sorting can be improved upon is a different debate,
t
41 matches
Mail list logo
