this patch implements CREATE SYNONYM
syntax:
CREATE SYNONYM [TABLE | INDEX | SEQUENCE | VIEW] synname ON orgname;
CREATE SYNONYM FUNCTION synname ON funcname(arg, arg, ...);
DROP SYNONYM [TABLE | INDEX | SEQUENCE | VIEW] synname;
DROP SYNONYM FUNCTION synname(arg, arg, ...);
for det
On Mar 7, 2006, at 17:29 , Hans-Jürgen Schönig wrote:
this patch implements CREATE SYNONYM
This feature is especially important to people who want to port
from Oracle to PostgreSQL (almost every customer who ports larger
Oracle applications will asked for it).
Is this SQL spec or Orac
this is actually what oracle is doing:
http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96540/statements_72a.htm
best regards,
hans
Michael Glaesemann wrote:
On Mar 7, 2006, at 17:29 , Hans-Jürgen Schönig wrote:
this patch implements CREATE SYNONYM
Thi
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Mar 7, 2006, at 17:29 , Hans-Jürgen Schönig wrote:
>> this patch implements CREATE SYNONYM
> Is this SQL spec or Oracle-specific?
This is not in the spec.
I'm inclined to reject this patch on the grounds that it doesn't do
what Oracle does and
On 3/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I'm inclined to reject this patch on the grounds that it doesn't dowhat Oracle does and does not look like it could be extended to do whatOracle does. My understanding is that what Oracle people mostly usesynonyms for is to provide cross-database acce
hi tom,
first of all thank you for looking into this so quickly.
Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
On Mar 7, 2006, at 17:29 , Hans-Jürgen Schönig wrote:
this patch implements CREATE SYNONYM
Is this SQL spec or Oracle-specific?
This is not in the spec.
I'd be glad to submit my patch and/or cleanup this one if its something
the community would be willing to accept.
we should definitely work together.
what is the status of your patch?
maybe we can discuss this off list?
thanks,
hans
--
Cybertec Geschwinde & Schönig G
On 3/7/06, Hans-Jürgen Schönig <[EMAIL PROTECTED]> wrote:
we should definitely work together.what is the status of your patch?maybe we can discuss this off list?
The last time I worked on it was on 8.0 (I think), but it wouldn't take
much to get it up to speed on 8.2. It's actually very similar to
On Tue, 7 Mar 2006, [ISO-8859-1] Hans-J?rgen Sch?nig wrote:
> > The semantics of namespace search seem wrong; I would think that a
> > synonym in schema A should mask a table in schema B if A precedes B
> > on the search path, but this doesn't work that way.
>
> good point.
> any other opionions
On 3/7/06, Stephan Szabo <[EMAIL PROTECTED]> wrote:
I'd personally be more interested in what the impact is on people notusing synonyms. How free is any search for synonyms if you aren't usingthe feature?
Unless synonym enablement were a configurable parameter
(which wouldn't really make sense), th
On Tue, 7 Mar 2006, Jonah H. Harris wrote:
> On 3/7/06, Stephan Szabo <[EMAIL PROTECTED]> wrote:
> >
> > I'd personally be more interested in what the impact is on people not
> > using synonyms. How free is any search for synonyms if you aren't using
> > the feature?
>
>
> Unless synonym enableme
On Tue, Mar 07, 2006 at 12:39:55PM -0800, Stephan Szabo wrote:
>
> On Tue, 7 Mar 2006, Jonah H. Harris wrote:
>
> > On 3/7/06, Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > >
> > > I'd personally be more interested in what the impact is on people not
> > > using synonyms. How free is any search fo
On Tue, 7 Mar 2006, Jim C. Nasby wrote:
> On Tue, Mar 07, 2006 at 12:39:55PM -0800, Stephan Szabo wrote:
> >
> > On Tue, 7 Mar 2006, Jonah H. Harris wrote:
> >
> > > On 3/7/06, Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I'd personally be more interested in what the impact is on peopl
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 7 Mar 2006, Jim C. Nasby wrote:
>> Wouldn't the cost only be incurred if you searched for something in
>> pg_class that wasn't there, and therefor had to fall back to pg_synonym?
> I think if synonyms were search path dependant that wouldn't be t
This patch implements some new aggregate functions defined by SQL2003:
stddev_pop(), stddev_samp(), var_pop(), and var_samp(). stddev_samp()
and var_samp() are identical to the existing stddev() and variance()
aggregates, so I've made the latter aliases for the former.
I noticed that SQL2003 does
Tom Lane wrote:
> (Actually, I don't think the case for table synonyms has been made
> adequately either; "Oracle has it" is *not* enough reason to take on
> another feature that we'll have to maintain forever, especially given
> that we're being told that one of the major use-cases for synonyms
>
On Tue, Mar 07, 2006 at 05:54:00PM -0500, Neil Conway wrote:
> This patch implements some new aggregate functions defined by SQL2003:
> stddev_pop(), stddev_samp(), var_pop(), and var_samp(). stddev_samp()
> and var_samp() are identical to the existing stddev() and variance()
> aggregates, so I've
On Tue, 2006-03-07 at 16:36 -0800, David Fetter wrote:
> The rationale is kinda mathematical. A measure of deviation from
> central tendency (i.e. variance or stddev) is something where you
> probably don't want to normalize the weights.
>
> For example, the standard deviation of {0,1,1,1,2} is a
On Tue, Mar 07, 2006 at 07:56:06PM -0500, Neil Conway wrote:
> On Tue, 2006-03-07 at 16:36 -0800, David Fetter wrote:
> > The rationale is kinda mathematical. A measure of deviation from
> > central tendency (i.e. variance or stddev) is something where you
> > probably don't want to normalize the
On 3/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
(Actually, I don't think the case for table synonyms has been madeadequately either; "Oracle has it" is *not* enough reason to take onanother feature that we'll have to maintain forever, especially given
that we're being told that one of the major use-
On 3/7/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:> (Actually, I don't think the case for table synonyms has been made> adequately either; "Oracle has it" is *not* enough reason to take on> another feature that we'll have to maintain forever, especially given
> that we're being to
Jonah H. Harris wrote:
> Now, one may argue that it's incorrect/bad application-design to not use
> fully qualified names, however, there are cases (especially in VERY large
> database applications) where you do not want to use fully qualified naming.
> In PostgreSQL, the alternative to synonyms i
On 3/7/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Well, if you don't want to have a monstrous search path with 130+schemas, then you'll have a monstrous amount of synonyms. Given thatschemas are a way to separate the object namespace, it seems moresensible to me to propagate the user of reasona
Neil Conway <[EMAIL PROTECTED]> writes:
> Well, I realize that stddev(DISTINCT x) != stddev(x) and that most
> people are going to be interested in stddev(x), but I don't think it's
> inconceivable for someone to be interested in stddev(DISTINCT x).
> Explicitly checking for and rejecting it doesn'
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Like I said, sometimes the user doesn't have a choice. Sure, it's easy to
> tell someone that has a 300-line PHP application to fix their code, but I've
> worked with people who have hundreds of thousands of lines of code and they
> don't just say,
Stephan Szabo wrote:
On Tue, 7 Mar 2006, Jonah H. Harris wrote:
On 3/7/06, Stephan Szabo <[EMAIL PROTECTED]> wrote:
I'd personally be more interested in what the impact is on people not
using synonyms. How free is any search for synonyms if you aren't using
the feature?
Unless synonym ena
One reason I like the alternative of putting synonym entries into the
regular catalogs is that it eliminates the need for extra searches:
you'd make exactly the same searches as you did before. Now, to the
extent that this requires making catalog entries longer, there'd be a
distributed overhead
What I don't really understand is what part of this cannot be achieved
by changing the search_path. The only case I can think of is when you
have tables A and B in schemas R and S, but you want to use R.A and S.B.
So there's no way to change search_path for this. But is this really
the intended
Alvaro Herrera wrote:
Jonah H. Harris wrote:
Now, one may argue that it's incorrect/bad application-design to not use
fully qualified names, however, there are cases (especially in VERY large
database applications) where you do not want to use fully qualified naming.
In PostgreSQL, the alterna
I agree with this to some extent.
The main use case, aside from database link objects, is really for
generally large applications such as a large ERP system. Most ERP
systems have a general or foundation-like schema where common objects
lie and each module is separated using schemas.
absolu
Tom Lane wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
Like I said, sometimes the user doesn't have a choice. Sure, it's easy to
tell someone that has a 300-line PHP application to fix their code, but I've
worked with people who have hundreds of thousands of lines of code and they
don'
On Wed, 8 Mar 2006, [ISO-8859-1] Hans-Jürgen Schönig wrote:
> Stephan Szabo wrote:
> > On Tue, 7 Mar 2006, Jonah H. Harris wrote:
> >
> >
> >>On 3/7/06, Stephan Szabo <[EMAIL PROTECTED]> wrote:
> >>
> >>>I'd personally be more interested in what the impact is on people not
> >>>using synonyms. How
32 matches
Mail list logo
