Skip site navigation (1) Skip section navigation (2)

Re: Imperfect solutions

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Imperfect solutions
Date: 2001-06-01 06:28:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> > > I think there are a few rules we can use to decide how to deal with
> > > imperfect solutions:
> >
> > You forgot
> >
> > * will the fix institutionalize user-visible behavior that will in the
> >   long run be considered the wrong thing?
> >
> > * will the fix contort new code that is written in the same vicinity,
> >   thereby making it harder and harder to replace as time goes on?
> >
> > The first of these is the core of my concern about %TYPE.
> I was thinking about this.  Seems if we want to emulate Oracle, we have
> to make %TYPE visible the way it is implemented in the patch.  We can
> make it track table changes or not, but it doesn't seem we have much
> latitude in how we make it visible to users.

I think Tom's argument was that just making it visisble will tie us up
also keep the semantics, which will be subtly different in PostgreSQL
Oracle and which can't be exactly emulated without emulating
in Oracle and thereby throwing away unique strengths of PostgreSQL.

Fortunately I've not heard very much support for making empty string and 
NULL to be the same ;)


In response to

pgsql-hackers by date

Next:From: Joe ConwayDate: 2001-06-01 06:31:51
Subject: Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:From: Pascal ScheffersDate: 2001-06-01 06:15:39
Subject: Re: Support for %TYPE in CREATE FUNCTION

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group