Awhile back I wrote:
I did some tests just now to determine the total number of catalog
entries associated with a simple table definition. Assuming it has
N user columns of built-in types (hence not requiring pg_depend entries
for the datatypes), I count
1 pg_class entry for the table
On 5/11/07, Tom Lane [EMAIL PROTECTED] wrote:
BTW, in the array patch as just committed, I was able to get rid of the
I am testing this feature, no problem so far. It's fast, and works
exactly as advertised! Great work! (aiui, no domain arrays for 8.3?)
merlin
I wrote:
OK, summarising what looks to me like a consensus position, ISTM the
plan could be:
. fix makeArrayTypeName() or similar to make it try harder to generate
a unique non-clashing name
. remove the existing 62 instead of 63 name length restrictions
. autogenerate array types for
On Sun, May 06, 2007 at 01:33:47PM -0400, Andrew Dunstan wrote:
However, there are still some oddities. For example, a change to or
removal of the base type affects the array type, but the array type
can be directly operated on (e.g. alter type _aa set schema foo ).
I'm inclined to say we
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
How would we do that? Not create the array types in bootstrap mode? Or
just special-case pg_statistic?
Not generate them in bootstrap mode works for me. IIRC, there's code
somewhere in there that allows anyarray to pass as a
Andrew Dunstan [EMAIL PROTECTED] writes:
Regarding catalog objects, we might have to try a little harder than
just not generating in bootstrap mode - IIRC we generate system views
(including pg_stats) in non-bootstrap mode. Maybe we just need to exempt
anything in the pg_catalog namespace.
On Mon, Apr 09, 2007 at 10:40:49AM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Regarding catalog objects, we might have to try a little harder than
just not generating in bootstrap mode - IIRC we generate system views
(including pg_stats) in non-bootstrap mode. Maybe
On Mon, Apr 09, 2007 at 10:14:41AM -0400, Andrew Dunstan wrote:
. defer for the present any consideration of a CREATE TYPE foo AS ARRAY
... command.
What is the rationale for allowing people to name the array type. When
I originally proposed the syntax I presumed that the array name would
be
Martijn van Oosterhout wrote:
On Mon, Apr 09, 2007 at 10:14:41AM -0400, Andrew Dunstan wrote:
. defer for the present any consideration of a CREATE TYPE foo AS ARRAY
... command.
What is the rationale for allowing people to name the array type. When
I originally proposed the syntax I
On Mon, Apr 09, 2007 at 04:07:16PM -0400, Andrew Dunstan wrote:
Some type systems have named array types, some don't. I can live happily
with either. Are array types anonymous in the standard?
Yes, they're anonymous in the standard. That doesn't mean we can't give
them names if we wanted...
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like you submitted a patch
Andrew Dunstan [EMAIL PROTECTED] writes:
One of the things that's been bothering me about this proposal is that
it leaves untouched and indeed greatly expands the scope of the typename
mangling we do. (i.e. adding an entry to pg_type with _ prepended).
Yeah, that's been bothering me too.
On Sun, Apr 08, 2007 at 07:08:38PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
One of the things that's been bothering me about this proposal is that
it leaves untouched and indeed greatly expands the scope of the typename
mangling we do. (i.e. adding an entry to
Tom Lane wrote:
I've been thinking of proposing that we add a column to pg_type that
points from a type to its array type (if any), ie the reverse link
from typelem. If we had that then the parser could follow that to
determine which type is foo[], instead of relying on the _foo naming
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't suggest that we stop using the naming convention,
but it would no longer be a hard-and-fast rule, just a convention.
In particular we could rejigger things around the edges to reduce
the name conflict problem. For instance the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't suggest that we stop using the naming convention,
but it would no longer be a hard-and-fast rule, just a convention.
In particular we could rejigger things around the edges to reduce
the name conflict
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm slightly inclined to agree with David that the danger of catalog
bloat isn't that great, and might not justify the extra work that some
sort of explicit array creation would involve (e.g. changes in grammar,
pg_dump), as long as we are agreed
Tom Lane wrote:
Based on this, I withdraw my efficiency concern about generating
rowtypes for all user tables. I do, however, still object to generating
them for system tables. In particular an array type for pg_statistic
will actively Not Work and probably constitute a security hole, because
Andrew Dunstan [EMAIL PROTECTED] writes:
How would we do that? Not create the array types in bootstrap mode? Or
just special-case pg_statistic?
Not generate them in bootstrap mode works for me. IIRC, there's code
somewhere in there that allows anyarray to pass as a column type in
bootstrap
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like you submitted a patch that entirely ignores multiple people's
On Tue, Apr 03, 2007 at 02:30:07AM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types
only on demand?
Scotched, as far as I could tell,
More like
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like you submitted a patch that entirely
On Fri, Mar 30, 2007 at 05:08:42PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
After several rounds of patches, it appears that it might be easier to
create a new typtype entry, which I'll tentatively call 'a' because it
seems a little fragile and a lot inelegant and hard
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
So, hum, what happened to the idea of creating the
Tom Lane wrote:
Why not enums? ;-)
Well, macros is how we do it elsewhere for char system columns.
I'm not sure we could rely on the behavior if we declared
pg_type.typtype as an enum type ... and if we don't, there's not
much point.
I was thinking C enums:
enum typtype_type {
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure we could rely on the behavior if we declared
pg_type.typtype as an enum type ... and if we don't, there's not
much point.
I was thinking C enums:
enum typtype_type {
TYPTYPE_BASE = 'b',
TYPTYPE_COMPOSITE
Tom Lane wrote:
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
The width is 4 both for the macro and the enum case. Both
Gregory Stark wrote:
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
TYPTYPE_BASE = 'b',
effectively generate int constants named TYPTYPE_BASE with decimal
value 98. So there are no storage advantages either way.
Gregory Stark [EMAIL PROTECTED] writes:
We could use enum {} to define the labels and then make a rule that
all actual variables should be declared using char rather than
declaring them as enum typtype. But I fear somebody would get that
wrong some day.
Yeah, that seems to me to be just
Tom Lane wrote:
It seems clear to me that this authorizes, but *does not require*,
the compiler to store an enum field in a byte or short instead of
an int when all the declared values will fit. So if we tried to
do this, we'd have the problem of needing compiler-specific data
type
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
It seems clear to me that this authorizes, but *does not require*,
the compiler to store an enum field in a byte or short instead of
an int when all the declared values will fit.
FWIW, I never meant to suggest using enums tuple
I wrote:
David Fetter [EMAIL PROTECTED] writes:
What parts of the code would need a once-over?
A lot :-( ... probably every place that touches typtype or typelem would
need at least a look. It'd be a good idea to take the opportunity to
start using macros for the values of typtype, as we
Tom Lane wrote:
I wrote:
David Fetter [EMAIL PROTECTED] writes:
What parts of the code would need a once-over?
A lot :-( ... probably every place that touches typtype or typelem would
need at least a look. It'd be a good idea to take the opportunity to
start using macros for the
On Sat, Mar 31, 2007 at 07:13:20PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
I wrote:
David Fetter [EMAIL PROTECTED] writes:
What parts of the code would need a once-over?
A lot :-( ... probably every place that touches typtype or typelem would
need at least a look. It'd be
David Fetter [EMAIL PROTECTED] writes:
What say we put one in pre-emptively for TYPTYPE_ARRAY?
When and if the patch appears, you can add it ;-). I'm just intending a
search-and-replace at the moment.
regards, tom lane
---(end of
On Sat, Mar 31, 2007 at 07:58:34PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
What say we put one in pre-emptively for TYPTYPE_ARRAY?
When and if the patch appears, you can add it ;-). I'm just intending a
search-and-replace at the moment.
Like this?
Cheers,
D
--
Bruce Momjian wrote:
I just realized that I need to check every usage of typtype to be
sure that the enums patch is sane. So, barring objection, I intend
to take this opportunity to make the code stop referring directly
to 'b', 'c' etc whereever possible. Any objections to these names?
Peter Eisentraut [EMAIL PROTECTED] writes:
I just realized that I need to check every usage of typtype to be
sure that the enums patch is sane. So, barring objection, I intend
to take this opportunity to make the code stop referring directly
to 'b', 'c' etc whereever possible. Any objections
On Fri, Mar 02, 2007 at 03:40:16PM -0800, David Fetter wrote:
Folks,
I'd like to take the TODO item that reads, Add support for arrays of
complex types, but before I start patching, I'd like to see whether
what I'm about to do makes any sense:
After several rounds of patches, it appears
David Fetter [EMAIL PROTECTED] writes:
After several rounds of patches, it appears that it might be easier to
create a new typtype entry, which I'll tentatively call 'a' because it
seems a little fragile and a lot inelegant and hard to maintain to
have typtype='c' and typrelid=InvalidOid mean,
On 2007-03-27, David Fetter [EMAIL PROTECTED] wrote:
Per further discussion with Andrew of Supernews and Merlin Moncure,
I've added a check for compound types and moved the creation of the
array type from DefineRelation in backend/commands/tablecmds.c to
heap_create_with_catalog in
On Wed, Mar 28, 2007 at 07:05:24AM -, Andrew - Supernews wrote:
On 2007-03-27, David Fetter [EMAIL PROTECTED] wrote:
Per further discussion with Andrew of Supernews and Merlin
Moncure, I've added a check for compound types and moved the
creation of the array type from DefineRelation in
David Fetter wrote:
The first is in type_sanity, which basically doesn't understand that
complex types now have array types associated with them and thinks
they're orphan array types, so it's actually the test that's not
right.
Hmm, I question the usefulness of automatically creating array
Alvaro Herrera wrote:
David Fetter wrote:
The first is in type_sanity, which basically doesn't understand that
complex types now have array types associated with them and thinks
they're orphan array types, so it's actually the test that's not
right.
Hmm, I question the usefulness of
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, I question the usefulness of automatically creating array types for
all relation types that are created -- the catalog bloat seems a bit too
much. An array of pg_autovacuum for example, does that make sense?
Not only that, it won't even work for
On Wed, Mar 28, 2007 at 01:33:56PM -0400, Andrew Dunstan wrote:
Alvaro Herrera wrote:
David Fetter wrote:
The first is in type_sanity, which basically doesn't understand
that complex types now have array types associated with them and
thinks they're orphan array types, so it's actually the
Tom Lane [EMAIL PROTECTED] writes:
CREATE ARRAY TYPE FOR foo
I also made a suggestion along the way that we never create array types
automatically except for domains. Ie, we don't need a new command, we just
document that what you do if you want to create an array of something is
create
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
CREATE ARRAY TYPE FOR foo
I also made a suggestion along the way that we never create array types
automatically except for domains.
That seems awfully strange, not to mention very non-backwards-compatible
since it
On Wed, Mar 28, 2007 at 03:24:26PM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
CREATE ARRAY TYPE FOR foo
I also made a suggestion along the way that we never create array
types automatically except for domains.
That seems awfully
On Tue, Mar 27, 2007 at 11:08:44AM -0700, David Fetter wrote:
On Sun, Mar 25, 2007 at 10:18:14PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it builds, it doesn't
David Fetter wrote:
It now initdb's successfully, but fails on a lot of regression tests.
Please find attached the new patch vs. CVS TIP and the regression test
output.
The regression test output is useless without seeing the regression diffs.
cheers
andrew
On Sun, Mar 25, 2007 at 10:18:14PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it builds, it doesn't
initdb. Enclosed are the patch and the error log.
Any hints as to
I wrote:
I'd like to take the TODO item that reads, Add support for arrays of
complex types, but before I start patching, I'd like to see whether
what I'm about to do makes any sense:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it
David Fetter [EMAIL PROTECTED] writes:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it builds, it doesn't
initdb. Enclosed are the patch and the error log.
Any hints as to what I might look at?
creating template1 database in
On Fri, Mar 02, 2007 at 06:59:50PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
1. In src/backend/commands/tablecmds.c, change DefineRelation as
follows:
* After the first call to heap_create_with_catalog, construct and
do another call to for the array type.
David Fetter [EMAIL PROTECTED] writes:
I noticed something in src/backend/commands/tablecmds.c which worries
me, namely that it ignores functions and views.
What?
regards, tom lane
---(end of broadcast)---
TIP 3: Have you
On Tue, Mar 06, 2007 at 04:14:07PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I noticed something in src/backend/commands/tablecmds.c which
worries me, namely that it ignores functions and views.
What?
The it in question is, find_composite_type_dependencies()
Cheers,
D
David Fetter [EMAIL PROTECTED] writes:
On Tue, Mar 06, 2007 at 04:14:07PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I noticed something in src/backend/commands/tablecmds.c which
worries me, namely that it ignores functions and views.
What?
The it in question is,
On Tue, Mar 06, 2007 at 04:24:36PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Tue, Mar 06, 2007 at 04:14:07PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I noticed something in src/backend/commands/tablecmds.c which
worries me, namely that it
On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
I'm still not happy about the idea of doing this for every relation
(and doing it for sequences and indexes would be the height of
wastefulness). How about we only do it for composite types?
I'm not happy about that. I agree
Martijn van Oosterhout wrote:
On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
I'm still not happy about the idea of doing this for every relation
(and doing it for sequences and indexes would be the height of
wastefulness). How about we only do it for composite types?
On Sat, Mar 03, 2007 at 09:06:11AM -0500, Andrew Dunstan wrote:
Martijn van Oosterhout wrote:
On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
I'm still not happy about the idea of doing this for every relation
(and doing it for sequences and indexes would be the height
David Fetter [EMAIL PROTECTED] writes:
2. Make a command: CREATE TYPE ARRAY OF foo;
The latter has the benefit of not restricting it to an arbitrary choice
of types, you could accept both domains and composite types here.
I'm thinking that DOMAINs over simple types should just
David Fetter wrote:
Per your earlier suggestion in IRC, I'm picturing a polymorphic
function like
pg_catalog.array_for(typepoid OID)
pg_catalog.array_for(typename NAME)
pg_catalog.array_for(typenamespace NAME, typename NAME)
I don't see a good reason to allow putting array types in a different
Folks,
I'd like to take the TODO item that reads, Add support for arrays of
complex types, but before I start patching, I'd like to see whether
what I'm about to do makes any sense:
1. In src/backend/commands/tablecmds.c, change DefineRelation as
follows:
* After the first call to
David Fetter [EMAIL PROTECTED] writes:
1. In src/backend/commands/tablecmds.c, change DefineRelation as
follows:
* After the first call to heap_create_with_catalog, construct and
do another call to for the array type.
I'm still not happy about the idea of doing this for every
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
1. In src/backend/commands/tablecmds.c, change DefineRelation as
follows:
* After the first call to heap_create_with_catalog, construct and
do another call to for the array type.
I'm still not happy about the idea of doing
70 matches
Mail list logo
