Uh, why worry? If you had an application that depended in any way
shape or form on the SET type, then I already broke it ...
Wasn't it a pg_upgrade consideration or something?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, p
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Yep, that's fine. I believe someone said that we'd never removed one
> before, but now we should be careful not to reuse the SET type OID?
Uh, why worry? If you had an application that depended in any way
shape or form on the SET type, then
Hm? I think the recent discussion was about contracting not to
arbitrarily reassign OIDs for existing types. Nobody said anything
about not being able to remove types, especially not ones as dead as
this doornail was.
Yep, that's fine. I believe someone said that we'd never removed one
before,
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> ... Remove the ancient SET entry
>> in pg_type, which is now highly unlikely to ever become used again.
> Hehe - speaking of how we never remove types :)
Hm? I think the recent discussion was about contracting not to
arbitrarily reassign OI
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Nice work. This is a cool unexpected step forward in functionality.
As recently as Thursday I didn't think this would get done for 7.5,
but I wanted to nibble off a few rough edges, and after a while there
weren't any left.
Or almost ... I just notice
Minor catalog cleanups for composite-type stuff. Adjust signatures shown
in pg_proc for record_in, record_out, etc to reflect that these routines
now make use of the second OID parameter. Remove the ancient SET entry
in pg_type, which is now highly unlikely to ever become used again.
Adjust type_
On Mon, Jun 07, 2004 at 01:04:48AM -0300, Tom Lane wrote:
> Log Message:
> ---
> Some preliminary documentation for composite-type stuff.
*sigh* Hard to keep up with this guy. I'm off a weekend and he's
already modified half the source tree. :-D
Nice work. This is a cool unexpected ste
Log Message:
---
Some preliminary documentation for composite-type stuff.
Modified Files:
--
pgsql-server/doc/src/sgml:
array.sgml (r1.34 -> r1.35)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/doc/src/sgml/array.sgml.diff?r1=1.34&r2=1.35)
Log Message:
---
Dept of second thoughts: don't use the new wide-character upper/lower
code if we are running in a single-byte encoding. No point in the
extra overhead in that case.
Modified Files:
--
pgsql-server/src/backend/utils/adt:
oracle_compat.c (r1.52 -> r1
Log Message:
---
Add some regression tests for composite-type operations.
Modified Files:
--
pgsql-server/src/test/regress:
parallel_schedule (r1.25 -> r1.26)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/parallel_schedule.diff?r
Log Message:
---
Allow use of table rowtypes directly as column types of other tables.
Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs
that would affect other tables' columns. Eventually we will probably
want to extend ALTER TABLE to actually do something useful her
Log Message:
---
Minor catalog cleanups for composite-type stuff. Adjust signatures shown
in pg_proc for record_in, record_out, etc to reflect that these routines
now make use of the second OID parameter. Remove the ancient SET entry
in pg_type, which is now highly unlikely to ever become
Log Message:
---
Add binary I/O support for composite types.
Modified Files:
--
pgsql-server/src/backend/utils/adt:
rowtypes.c (r1.2 -> r1.3)
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/rowtypes.c.diff?r1=1.2&r2=1.3)
13 matches
Mail list logo
