Hi Mark,
actually there is a simple way to determine this.
create an entity relationship model, try to build a 3rd normal form,
look on what the users/customers are really doing, not only what data
they are dealing with and finally break up the 3rd NF again.
A table with too many columns is as
Re: attribute ordering
The column presentation issue maybe should be
cross referenced with the problem with rowtypes
where the referenced table has dropped columns.
This is the one where in plpgsql you do a select *
into a rowtype of a table with dropped columns
you get a mismatch on the types.
I have a Red Hat 7.3 box, and I updated from PostgreSQL 7.2.3 to 7.3.3
via RPM (the PGDG RPMs). When I did so, Perl DBD::Pg routines started
failing, breaking various scripts, and I had to downgrade to PostgreSQL
7.2.3 again in somewhat of a rush as I sorted things out.
The problem was that the
В Сбт, 28.06.2003, в 06:36, Tom Lane пишет:
> regards, tom lane
> Red Hat Database project
Heh, it's now "PostgreSQL - Red Hat Edition Project" :)
--
Markus Bertheau.
Berlin, Berlin.
Germany.
---(end of broadcast)--
On Thu, Jun 26, 2003 at 02:12:22PM +0100, Richard Huxton wrote:
> It looks like he has a centralised "address" table with "customer_addresses"
> linking "customer" to "address". Likewise for "supplier".
>
> His problem was he wanted to remove address details when nothing referred to
> them an
On Sat, Jun 28, 2003 at 02:21:57PM -0400, Tom Lane wrote:
> Right, I was just thinking of this as an optimization we'd apply during
> initial table creation. Renumbering columns later on would be a huge
> mess, far more work than the optimization is worth.
perhaps it could be done on VACUUM ?
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > However, I am not sure how useful NOT NULL is in practice because there
> > are lots of columns that don't specify NOT NULL but have mostly nulls or
> > mostly non-nulls, which kills our caching --- what I was hoping to do
> > some day
Bruce Momjian <[EMAIL PROTECTED]> writes:
> However, I am not sure how useful NOT NULL is in practice because there
> are lots of columns that don't specify NOT NULL but have mostly nulls or
> mostly non-nulls, which kills our caching --- what I was hoping to do
> some day was to cache the null bit
Alvaro Herrera wrote:
On Sat, Jun 28, 2003 at 01:43:32PM -0400, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this a TODO?
>When columns can be reordered, move varlena columns to the end?
I believe that really what you want is fixed-width NOT NULL columns
first, then fixed-widt
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> This means that when you do ALTER TABLE ... SET/DROP NOT NULL the table
>> may have to be completely rewritten?
> I don't think we would change any physical ordering with ALTER TABLE ---
> just do it when the table is created, if
Alvaro Herrera wrote:
> On Sat, Jun 28, 2003 at 01:43:32PM -0400, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Is this a TODO?
> > > When columns can be reordered, move varlena columns to the end?
> >
> > I believe that really what you want is fixed-width NOT NULL columns
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this a TODO?
> > When columns can be reordered, move varlena columns to the end?
>
> Yeah, if it's not in there already. I remember seeing some Berkeley-era
> comments speculating that this would be a good thing to do. Not su
On Sat, Jun 28, 2003 at 01:43:32PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this a TODO?
> > When columns can be reordered, move varlena columns to the end?
>
> I believe that really what you want is fixed-width NOT NULL columns
> first, then fixed-width nullab
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this a TODO?
> When columns can be reordered, move varlena columns to the end?
Yeah, if it's not in there already. I remember seeing some Berkeley-era
comments speculating that this would be a good thing to do. Not sure if
they're still in the
Is this a TODO?
When columns can be reordered, move varlena columns to the end?
---
Jan Wieck wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Is the issue of many columns in a tuple the
Doug McNaught <[EMAIL PROTECTED]> writes:
> What about making network connections? That seems less harmful than
> filesystem access, and certainly could have legitimate uses.
Any outside-the-database operation "could have legitimate uses". The
problem is it also has not-so-legitimate uses, and w
Rajesh Kumar Mallah wrote:
Hi Folks,
Shudnt' messages like
ERROR: value too long for type character varying(5)
Maybe, yes. It's just not that trivial to do.
MySQL is better in these small things.
I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other k
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Is the issue of many columns in a tuple the same issue as a SELECT
having many columns?
I believe all the same inefficiencies need to be fixed whichever
way you look at it. Probably "many columns in SELECT" is the more
accurate description
Tom Lane <[EMAIL PROTECTED]> writes:
> elein <[EMAIL PROTECTED]> writes:
> > Exactly what functions are prohibited (or acceptable)
> > for a pl language in PostgreSQL to become trusted?
> > Is the exact criteria list documented somewhere?
>
> We don't have a formal definition, but I'd say a minim
19 matches
Mail list logo
