On 05/09/2017 07:03 PM, Armand Pirvu (home) wrote:
On May 9, 2017, at 7:11 PM, Adrian Klaver wrote:
On 05/09/2017 05:02 PM, armand pirvu wrote:
Well
Jt1 is prod and jt2 is dev
You are talking schemas, not databases, correct?
Correct
Before someone pushes to prod it does work in dev.
On May 9, 2017, at 7:11 PM, Adrian Klaver wrote:
> On 05/09/2017 05:02 PM, armand pirvu wrote:
>> Well
>> Jt1 is prod and jt2 is dev
>
> You are talking schemas, not databases, correct?
>
>
Correct
>> Before someone pushes to prod it does work in dev. The jdbc connection
>
> That would co
On 05/09/2017 05:02 PM, armand pirvu wrote:
Well
Jt1 is prod and jt2 is dev
You are talking schemas, not databases, correct?
Before someone pushes to prod it does work in dev. The jdbc connection
That would concern me, as anything bad that happened in the dev schema
could bring the entir
Well
Jt1 is prod and jt2 is dev
Before someone pushes to prod it does work in dev. The jdbc connection routes
to jt2. In the mean time it wad needed that some tables in prod are synced at
all times from dev. Hence the view/fdw.
What I meant by connections was more to say the type of load or user
On 05/09/2017 02:36 PM, Armand Pirvu (home) wrote:
Hi
I have two schemas jt1, and jt2 in the same db
In both I have the same table tbl3
The idea is to keep in sync jt1.tbl3 from jt2.tbl3 each time I have an
insert/update/delete on jt2.tbl3
So I was thinking about the following cases to avoid r
Hi
I have two schemas jt1, and jt2 in the same db
In both I have the same table tbl3
The idea is to keep in sync jt1.tbl3 from jt2.tbl3 each time I have an
insert/update/delete on jt2.tbl3
So I was thinking about the following cases to avoid replication
1) in jt2 rather than have the tbl3 tab
On Thu, May 9, 2013 at 4:33 PM, itishree sukla wrote:
> Hi all,
>
> Is there any way, i can know what all views are there on a table by a sql
> query?
>
>
> Regards,
> Itishree
>
Try this...
select table_name,view_name from information_schema.view_table_usage where
table_name='table_name';
---
Hi all,
Is there any way, i can know what all views are there on a table by a sql
query?
Regards,
Itishree
On Wed, Aug 29, 2012 at 8:52 AM, Chris Travers wrote:
> ALTER TABLE fruit ADD apple_id int;
> ALTER TABLE fruit ADD FOREIGN KEY (apple_id, type)
>REFERENCES apple (fruit_id, type)
>DEFERRABLE INITIALLY DEFERRED;
>
> And then do the same for orange etc. you can then:
>
> AL
2012/8/29 Merlin Moncure
> On Tue, Aug 28, 2012 at 3:25 PM, Dmitriy Igrishin
> wrote:
> > 2012/8/20 Merlin Moncure
> >>
> >> On Sun, Aug 19, 2012 at 8:14 AM, Dmitriy Igrishin
> >> wrote:
> >> >> For various reasons, this often goes the wrong way. Views are often
> >> >> the right way to go.
On Wed, Aug 29, 2012 at 6:15 AM, Merlin Moncure wrote:
>
> Hm, couple points (and yes, this is a common problem):
> *) how come you don't have your function depend on the table instead
> of the view? this has the neat property of having the function
> automatically track added columns to the tab
On Tue, Aug 28, 2012 at 3:25 PM, Dmitriy Igrishin wrote:
> 2012/8/20 Merlin Moncure
>>
>> On Sun, Aug 19, 2012 at 8:14 AM, Dmitriy Igrishin
>> wrote:
>> >> For various reasons, this often goes the wrong way. Views are often
>> >> the right way to go. +1 on your comment above -- the right way t
2012/8/20 Merlin Moncure
> On Sun, Aug 19, 2012 at 8:14 AM, Dmitriy Igrishin
> wrote:
> >> For various reasons, this often goes the wrong way. Views are often
> >> the right way to go. +1 on your comment above -- the right way to do
> >> views (and SQL in general) is to organize scripts and to
On Sun, Aug 19, 2012 at 8:14 AM, Dmitriy Igrishin wrote:
>> For various reasons, this often goes the wrong way. Views are often
>> the right way to go. +1 on your comment above -- the right way to do
>> views (and SQL in general) is to organize scripts and to try and avoid
>> managing everything
2012/8/18 Merlin Moncure
> On Fri, Aug 17, 2012 at 5:44 PM, Tom Lane wrote:
> > Adam Mackler writes:
> >> I notice when I save a view, I lose all the formatting and comments.
> >> As I was writing a complicated view, wanting to retain the format and
> >> comments, I thought I could just save it
On 08/18/2012 06:49 AM, Merlin Moncure wrote:
For various reasons, this often goes the wrong way. Views are often
the right way to go.
Indeed. I've had queries speed up *hundreds* of times when I convert a
function the planner didn't seem to want to inline into a view it can
push conditions
On Fri, Aug 17, 2012 at 2:35 PM, Adam Mackler wrote:
> Hi:
>
> I notice when I save a view, I lose all the formatting and comments.
> As I was writing a complicated view, wanting to retain the format and
> comments, I thought I could just save it as a function that returns a
> table value. A fun
"David Johnston" writes:
> Trying to answer the previous question this one presented itself: I just
> tried a couple of very simple queries and couldn't get them give me a plan
> that wasn't a "Function Scan". Is it possible that only "scalar" functions
> can be inlined?
> CREATE OR REPLACE FUN
Included below:
1) Question regarding the ability to inline set-returning functions
2) A comment that not keeping the content between the "CREATE VIEW ... AS"
and the trailing ";|EOF" is losing good information to have inside the
database.
> Correct. The reparse time per se is generally not a b
> Hi:
>
> I notice when I save a view, I lose all the formatting and comments.
> As I was writing a complicated view, wanting to retain the format and
> comments, I thought I could just save it as a function that returns a
> table value. A function would evaluate to the same value as a view,
>
On Fri, Aug 17, 2012 at 5:44 PM, Tom Lane wrote:
> Adam Mackler writes:
>> I notice when I save a view, I lose all the formatting and comments.
>> As I was writing a complicated view, wanting to retain the format and
>> comments, I thought I could just save it as a function that returns a
>> tabl
Adam Mackler writes:
> I notice when I save a view, I lose all the formatting and comments.
> As I was writing a complicated view, wanting to retain the format and
> comments, I thought I could just save it as a function that returns a
> table value. A function would evaluate to the same value as
Hi:
I notice when I save a view, I lose all the formatting and comments.
As I was writing a complicated view, wanting to retain the format and
comments, I thought I could just save it as a function that returns a
table value. A function would evaluate to the same value as a view,
but changing it
On Wed, Apr 4, 2012 at 12:51 PM, Thomas Kellerer wrote:
> Jon Nelson wrote on 04.04.2012 19:47:
>
>>> What about a set-returning function that builds the query dynamically and
>>> wrapping that into a view?
>>>
>>> That way the view would never change and client would still have the
>>> perspectiv
Jon Nelson wrote on 04.04.2012 19:47:
What about a set-returning function that builds the query dynamically and
wrapping that into a view?
That way the view would never change and client would still have the
perspective of a view/table
Your function could pick up the changes automatically e.g.
On Wed, Apr 4, 2012 at 12:47 PM, Jon Nelson wrote:
> On Wed, Apr 4, 2012 at 11:22 AM, Thomas Kellerer wrote:
>> Jon Nelson wrote on 04.04.2012 15:50:
>>
>>> I need to have something table-like from the client's perspective for
>>> a bunch of reasons.
>>> For now, assume that I want to keep using
On Wed, Apr 4, 2012 at 11:22 AM, Thomas Kellerer wrote:
> Jon Nelson wrote on 04.04.2012 15:50:
>
>> I need to have something table-like from the client's perspective for
>> a bunch of reasons.
>> For now, assume that I want to keep using the view and that I'd like
>> to find better ways to addres
Jon Nelson wrote on 04.04.2012 15:50:
I need to have something table-like from the client's perspective for
a bunch of reasons.
For now, assume that I want to keep using the view and that I'd like
to find better ways to address my concerns.
What about a set-returning function that builds the qu
On Wed, Apr 4, 2012 at 10:43 AM, Tom Lane wrote:
> Jon Nelson writes:
>> On Wed, Apr 4, 2012 at 9:01 AM, Tom Lane wrote:
>>> Why aren't you using a standard partitioned table, cf
>>> http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
>
>> Because I'm adding "scalar" (constant-value)
Jon Nelson writes:
> On Wed, Apr 4, 2012 at 9:01 AM, Tom Lane wrote:
>> Why aren't you using a standard partitioned table, cf
>> http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
> Because I'm adding "scalar" (constant-value) columns to the view like this:
> SELECT * from tableA, D
On Wed, Apr 4, 2012 at 9:01 AM, Tom Lane wrote:
>
> Why aren't you using a standard partitioned table, cf
> http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
Because I'm adding "scalar" (constant-value) columns to the view like this:
SELECT * from tableA, DATE 'date string here' as
Jon Nelson writes:
> I need to have something table-like from the client's perspective for
> a bunch of reasons.
> For now, assume that I want to keep using the view and that I'd like
> to find better ways to address my concerns.
Why aren't you using a standard partitioned table, cf
http://www.po
On Wed, Apr 4, 2012 at 8:50 AM, Jon Nelson wrote:
>
> I need to have something table-like from the client's perspective for
> a bunch of reasons.
> For now, assume that I want to keep using the view and that I'd like
> to find better ways to address my concerns.
hence my question upthread: "how s
On Tue, Apr 3, 2012 at 8:58 PM, Scott Marlowe wrote:
> On Tue, Apr 3, 2012 at 7:21 PM, Jon Nelson wrote:
>> On Tue, Apr 3, 2012 at 2:45 PM, Thomas Kellerer wrote:
>>> Jon Nelson wrote on 03.04.2012 20:41:
>>>
Close, but not quite. It's not rotation but every N minutes a
newly-built tab
On Tue, Apr 3, 2012 at 7:21 PM, Jon Nelson wrote:
> On Tue, Apr 3, 2012 at 2:45 PM, Thomas Kellerer wrote:
>> Jon Nelson wrote on 03.04.2012 20:41:
>>
>>> Close, but not quite. It's not rotation but every N minutes a
>>> newly-built table appears. I'd like that table to appear as part of
>>> the
On Tue, Apr 3, 2012 at 2:45 PM, Thomas Kellerer wrote:
> Jon Nelson wrote on 03.04.2012 20:41:
>
>> Close, but not quite. It's not rotation but every N minutes a
>> newly-built table appears. I'd like that table to appear as part of
>> the view as soon as possible.
>
>
> Can't you use table inheri
On Tue, Apr 3, 2012 at 1:45 PM, Thomas Kellerer wrote:
> Jon Nelson wrote on 03.04.2012 20:41:
>
>> Close, but not quite. It's not rotation but every N minutes a
>> newly-built table appears. I'd like that table to appear as part of
>> the view as soon as possible.
>
>
> Can't you use table inheri
Jon Nelson wrote on 03.04.2012 20:41:
Close, but not quite. It's not rotation but every N minutes a
newly-built table appears. I'd like that table to appear as part of
the view as soon as possible.
Can't you use table inheritance for that?
--
Sent via pgsql-general mailing list (pgsql-gener
On Tue, Apr 3, 2012 at 1:41 PM, Jon Nelson wrote:
> On Tue, Apr 3, 2012 at 1:36 PM, Merlin Moncure wrote:
>> Generally speaking, in SQL, locks are held until the transaction
>> commits; there are tons of reasons why things have to work that way.
>> Anyways, I'm betting your requirement to have to
On Tue, Apr 3, 2012 at 1:36 PM, Merlin Moncure wrote:
> On Tue, Apr 3, 2012 at 12:30 PM, Jon Nelson wrote:
>> On Tue, Apr 3, 2012 at 12:16 PM, Merlin Moncure wrote:
>>> On Tue, Apr 3, 2012 at 12:01 PM, Jon Nelson
>>> wrote:
I have a situation that I'd like some help resolving.
Using
On Tue, Apr 3, 2012 at 12:30 PM, Jon Nelson wrote:
> On Tue, Apr 3, 2012 at 12:16 PM, Merlin Moncure wrote:
>> On Tue, Apr 3, 2012 at 12:01 PM, Jon Nelson
>> wrote:
>>> I have a situation that I'd like some help resolving.
>>> Using PostgreSQL 8.4. on Linux, I have three things
>>> coming toget
Jon Nelson wrote on 03.04.2012 19:01:
I also update this view with CREATE OR REPLACE VIEW every 15-30 minutes
That is a highly questionable approach.
What real problem are you trying to solve with that?
Maybe there is a better solution that does not require changing the view.
--
Sent via p
On Tue, Apr 3, 2012 at 12:16 PM, Merlin Moncure wrote:
> On Tue, Apr 3, 2012 at 12:01 PM, Jon Nelson wrote:
>> I have a situation that I'd like some help resolving.
>> Using PostgreSQL 8.4. on Linux, I have three things
>> coming together that cause me pain. I have a VIEW used by a bunch of
>> qu
On Tue, Apr 3, 2012 at 12:01 PM, Jon Nelson wrote:
> I have a situation that I'd like some help resolving.
> Using PostgreSQL 8.4. on Linux, I have three things
> coming together that cause me pain. I have a VIEW used by a bunch of
> queries. Usually, these queries are fairly short (subsecond) but
I have a situation that I'd like some help resolving.
Using PostgreSQL 8.4. on Linux, I have three things
coming together that cause me pain. I have a VIEW used by a bunch of
queries. Usually, these queries are fairly short (subsecond) but
sometimes they can be very long (days). I also update this
On 05/24/2011 10:04 AM, salah jubeh wrote:
Hello Adrian,
I have changed the permission of one table where view B depend on and my
problem is over. Still; the whole issue is confusing me.
See here for explanation:
http://www.postgresql.org/docs/9.0/interactive/sql-createview.html
"Access to tab
PM
Subject: Re: [GENERAL] Views permision -- please help and suggestion
On Tuesday, May 24, 2011 6:50:38 am salah jubeh wrote:
> I have two views A and B such that A depend on B. Both of them has the same
> permissions.
What are the permissions?
>
>
> when I excute
>
> S
On Tuesday, May 24, 2011 6:50:38 am salah jubeh wrote:
> I have two views A and B such that A depend on B. Both of them has the same
> permissions.
What are the permissions?
>
>
> when I excute
>
> SELECT * FROM A;
Who are you executing the above as?
>
> ERROR: permission denied for relat
I have two views A and B such that A depend on B. Both of them has the same
permissions.
when I excute
SELECT * FROM A;
ERROR: permission denied for relation B
** Error **
ERROR: permission denied for relation B
SQL state: 42501
However, I can do
SELECT * FROM B;
H
- Forwarded Message -
From: salah jubeh
To: Tom Lane
Cc: pgsql
Sent: Friday, May 20, 2011 3:54 PM
Subject: Re: [GENERAL] Views permessions
I have found the table where views are roles- permissions are stored and I
checked it automatically and still permissions are identical i.e
a bug or something like that...
Regards
From: Tom Lane
To: salah jubeh
Cc: pgsql
Sent: Friday, May 20, 2011 3:47 PM
Subject: Re: [GENERAL] Views permessions
salah jubeh writes:
> There is a problem confusing me. I have two views 'VIEW1' and '
salah jubeh writes:
> There is a problem confusing me. I have two views 'VIEW1' and 'VIEW2'
> 1. VIEW2 depends on VIEW1
> 2. VIEW2 and VIEW1 have the exact permissions
> 3. I can execute SELECT * from VIEW1 ; without problem
> 4. When I execute SELECT * from VIEW2; I get
> ERROR: permissio
Hello Guys,
There is a problem confusing me. I have two views 'VIEW1' and 'VIEW2'
1. VIEW2 depends on VIEW1
2. VIEW2 and VIEW1 have the exact permissions
3. I can execute SELECT * from VIEW1 ; without problem
4. When I execute SELECT * from VIEW2; I get
ERROR: permission denied for rel
On 26/02/2011 15:04, Zery wrote:
Hi,
I'm new in database world, but I know postgres for a long time ago. Now
I'm trying to focusing on developing a database using postgresql and
postgis extension. I have several question that needs help from all of you.
1. I understand about a view, the lack fo
Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Zery
Sent: Saturday, February 26, 2011 10:05 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] views and categorized tables
Hi,
I'm new in database world, but I
Hi,
I'm new in database world, but I know postgres for a long time ago. Now
I'm trying to focusing on developing a database using postgresql and
postgis extension. I have several question that needs help from all of you.
1. I understand about a view, the lack for me is I cannot edit a view
One of the benefits of writing views instead of using SQL in your code,
is that any developer or developer tool can use the view.
So the DB developer writes the view and maybe define indexes that can
speed up the query and any developer of any software that uses the DB
can refer to the View instead
On 04/11/2010 19:58, Chris Browne wrote:
Under the hood, views represent a rewriting of the query.
http://www.postgresql.org/docs/8.4/static/rules-views.html
If you have two tables that are joined together, in a view, then when
you query the view, you're really running a more complex query
te...@chosen-ones.org (Terry Lee Tucker) writes:
> Lately, I've begun using views quite often especially when queries for
> various
> reports, etc. become complicated. I am now wondering if there is a price to
> pay in terms of overhead for this. In truth, I don't really understand how a
> view
On Thursday, November 04, 2010 15:03:49 Scott Marlowe wrote:
> On Thu, Nov 4, 2010 at 12:43 PM, Terry Lee Tucker
wrote:
> > Greetings:
> >
> > Lately, I've begun using views quite often especially when queries for
> > various reports, etc. become complicated. I am now wondering if there is
> > a
On Thu, Nov 4, 2010 at 12:43 PM, Terry Lee Tucker wrote:
> Greetings:
>
> Lately, I've begun using views quite often especially when queries for various
> reports, etc. become complicated. I am now wondering if there is a price to
> pay in terms of overhead for this. In truth, I don't really under
Greetings:
Lately, I've begun using views quite often especially when queries for various
reports, etc. become complicated. I am now wondering if there is a price to
pay in terms of overhead for this. In truth, I don't really understand how a
view works. I know that it takes on many of the attr
Christian Schröder wrote:
> Indeed, you are right! Granting select permission to the "ts_frontend"
> user (more precisely: granting membership to the "zert_readers" role)
> solved the problem.
>
>> This is strange because ts_frontend can select from "EDITORS" because
>> of the membership to role
Tom Lane wrote:
Table accesses done by a view are checked according to the privileges
of the owner of the view, not of whoever invoked the view. It's a
bit inconsistent because function calls done in the view are not handled
that way (though I hope we change them to match, someday).
Phew, som
=?ISO-8859-1?Q?Christian_Schr=F6der?= <[EMAIL PROTECTED]> writes:
> Albe Laurenz wrote:
>> This is strange because ts_frontend can select from "EDITORS" because
>> of the membership to role zert_readers.
>>
> No, the user "ts_frontend" is (was) not a member of the group
> "zert_readers", but the
Albe Laurenz wrote:
User ts_frontend, the owner of the view ts_frontend.v_editors, does not
have the SELECT privilege on the underlying table public."EDITORS".
Because of that neither he nor anybody else can select from the view,
although ts_frontend is able to create the view.
Indeed, you ar
Christian Schröder wrote:
>> Can you show us the permissions for "ts_frontend.v_editors" as well
>> as for any "EDITORS" table you find (e.g. using \z in psql).
>>
> Access privileges for database "zertifikate"
> Schema | Name | Type | Access pr
Albe Laurenz wrote:
One possibility I see is that there is more than one table
called "EDITORS" and they get confused.
What do you get when you
SELECT t.oid, n.nspname, t.relname
FROM pg_catalog.pg_class t JOIN
pg_catalog.pg_namespace n ON t.relnamespace = n.oid
WHERE t.relname='EDITORS';
Christian Schröder wrote:
> yesterday I moved our database from one server to another. I
> did a full
> dump of the database and imported the dump into the new server. Since
> then I have a strange problem which I cannot explain ...
> I have a table public."EDITORS":
>
> Table
Hi list,
yesterday I moved our database from one server to another. I did a full
dump of the database and imported the dump into the new server. Since
then I have a strange problem which I cannot explain ...
I have a table public."EDITORS":
Table "public.EDITORS"
Column |
Tom Lane wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>> On 05/10/07 21:24, Tom Lane wrote:
>>> My instinctive CS-major reply to that is "only if you've found a
>>> solution to the halting problem". However, it's possible that we could
>>> detect this case for a useful subset of real-world fun
On Fri, 11 May 2007 04:24:55 +0200, Tom Lane <[EMAIL PROTECTED]> wrote:
"Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
Would it be reasonable to suggest that later versions of PostgreSQL
could examine if a function changes data, and quietly marks a function
as 'stable' if it doesn't?
My ins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/10/07 22:21, Tom Lane wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>> On 05/10/07 21:24, Tom Lane wrote:
>>> My instinctive CS-major reply to that is "only if you've found a
>>> solution to the halting problem". However, it's possible that w
Ron Johnson <[EMAIL PROTECTED]> writes:
> On 05/10/07 21:24, Tom Lane wrote:
>> "Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
>>> Would it be reasonable to suggest that later versions of PostgreSQL
>>> could examine if a function changes data, and quietly marks a function
>>> as 'stable' if i
Ron Johnson <[EMAIL PROTECTED]> writes:
> On 05/10/07 21:24, Tom Lane wrote:
>> My instinctive CS-major reply to that is "only if you've found a
>> solution to the halting problem". However, it's possible that we could
>> detect this case for a useful subset of real-world functions ... not
>> sure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/10/07 21:24, Tom Lane wrote:
> "Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
>> Would it be reasonable to suggest that later versions of PostgreSQL
>> could examine if a function changes data, and quietly marks a function
>> as 'stable' if i
"Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
> Would it be reasonable to suggest that later versions of PostgreSQL
> could examine if a function changes data, and quietly marks a function
> as 'stable' if it doesn't?
My instinctive CS-major reply to that is "only if you've found a
solution t
On Thu, 10 May 2007 00:06:06 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> ... I suspect the
> important point here is that if you have
>
> CREATE VIEW v AS SELECT sis, boom, bah ...
>
> then
>
> SELECT ... FROM ..., v, ...
>
> will be rewritten to the same parsetree as if you'd written
>
> SE
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> Two people now have stated without much qualification that views have
> some kind of associated performance (Brent Woods) or optimization
> (Dann Corbit) penalty. Where does this idea come from? Views in
> PostgreSQL are just rewritten with the
On Thursday 10. May 2007 21:21, Tom Lane wrote:
>"Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
>> I haven't pondered the subtleties of 'stable', 'immutable' or
>> 'volatile' yet, but rather reckoned that the default would do.
>
>Yeah, I was against this particular change actually, because I
>
"Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
> On Thursday 10. May 2007 19:23, Tom Lane wrote:
>> Are get_parent() and/or get_pbdate() marked volatile by any chance?
>> 8.2 is more conservative about optimizing sub-selects involving
>> volatile functions than previous releases were, because we
On Thursday 10. May 2007 19:23, Tom Lane wrote:
>"Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
>> CREATE OR REPLACE VIEW tmg_persons AS
>> SELECT
>> person_id,
>> get_parent(person_id,1) AS father_id,
>> get_parent(person_id,2) AS mother_id,
>> last_edit,
>> get_pbdate(pers
"Leif B. Kristensen" <[EMAIL PROTECTED]> writes:
> [ this query got slow in 8.2: ]
> $query = "select person_id, pb_date from tmg_persons
> where father_id = $p or mother_id = $p
> order by pb_date";
> tmg_persons is a view involving several function calls, and
Ashish Karalkar wrote:
> Hello All,
>
> Can anybody please point me to Advantages and Disadvantages of using view
>
>
> With Regards
> Ashish...
Well, IMHO views are part of the "business logic" and not of the data
model. You can also think of them as an API to access the data from
applications
On Wednesday 9. May 2007 06:32, Ashish Karalkar wrote:
>Hello All,
>
>Can anybody please point me to Advantages and Disadvantages of using
> view
Sometimes, a view can fool you into writing hideously expensive queries
just because it is the first method that comes to mind.
I upgraded to version
Joshua D. Drake wrote:
Brent Wood wrote:
Ashish Karalkar wrote:
Thanks Brent for your replay,
What about the Disadvantages, Performance issues?
As far as I'm aware, performance is the only real disadvantage.
What performance are we talking about here? Executing from a view
although has *
eral@postgresql.org
>> Subject: Re: [GENERAL] Views- Advantages and Disadvantages
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 05/09/07 15:18, Dann Corbit wrote:
>> [snip]
>>> That is a significant achievement, since many databas
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-general-
> [EMAIL PROTECTED] On Behalf Of Ron Johnson
> Sent: Wednesday, May 09, 2007 6:07 PM
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Views- Advantages and Disadvantages
>
> -
On May 9, 2007, at 19:58 , Joshua D. Drake wrote:
Brent Wood wrote:
Ashish Karalkar wrote:
Thanks Brent for your replay,
What about the Disadvantages, Performance issues?
As far as I'm aware, performance is the only real disadvantage.
What performance are we talking about here? Executing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/07 15:18, Dann Corbit wrote:
[snip]
>
> That is a significant achievement, since many database systems do not
> have that ability.
Maybe (probably!) back in the Oracle 6 days, but cost-based
optimizers have done this for *years*.
- --
Ron J
Brent Wood wrote:
Ashish Karalkar wrote:
Thanks Brent for your replay,
What about the Disadvantages, Performance issues?
As far as I'm aware, performance is the only real disadvantage.
What performance are we talking about here? Executing from a view
although has *some* overhead, I don't
Ashish Karalkar wrote:
Thanks Brent for your replay,
What about the Disadvantages, Performance issues?
As far as I'm aware, performance is the only real disadvantage.
I tend to break DB design into stages:
ER modelling to define the entities/relationships the DB needs to
store/represent
N
--- Reece Hart <[EMAIL PROTECTED]> wrote:
> I believe that you're mistaken, and you can see it rather easily by
> explaining a select on a view (or even a view of views). For example:
> View definition:
> SELECT pa.palias_id, pv.pseq_id, pa.origin_id, pa.alias,
> pa.descr,
On Wed, 2007-05-09 at 12:02 -0700, Dann Corbit wrote:
> Views can hide important information from the optimizer (especially
> index information).
I believe that you're mistaken, and you can see it rather easily by
explaining a select on a view (or even a view of views). For example:
[EMA
Views can hide important information from the optimizer (especially
index information).
Really? AIUI, views-at least in PostgreSQL-are implemented using
PostgreSQL's rule system: the entire query is rewritten to include
the view query, and the optimizer sees the rewritten query. What the
optimi
Dann Corbit wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-general-
[EMAIL PROTECTED] On Behalf Of Ashish Karalkar
Sent: Wednesday, May 09, 2007 1:36 AM
To: Andrej Ricnik-Bay; Ron Johnson
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Views- Advantages and
> -Original Message-
> From: Michael Glaesemann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 09, 2007 12:14 PM
> To: Dann Corbit
> Cc: Ashish Karalkar; Andrej Ricnik-Bay; Ron Johnson; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Views- Advantages and Disadva
On May 9, 2007, at 14:02 , Dann Corbit wrote:
Views can hide important information from the optimizer (especially
index information).
Really? AIUI, views—at least in PostgreSQL—are implemented using
PostgreSQL's rule system: the entire query is rewritten to include
the view query, and the
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-general-
> [EMAIL PROTECTED] On Behalf Of Ashish Karalkar
> Sent: Wednesday, May 09, 2007 1:36 AM
> To: Andrej Ricnik-Bay; Ron Johnson
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL]
On May 9, 2007, at 4:36 AM, Ashish Karalkar wrote:
Thanks All for your replies,
But then dont we have any disadvantage of using View???
With Reagrds
Ashish...
I once inherited a database that made extensive use of constants in
views (a la magic numbers) as well as had several instance
1 - 100 of 155 matches
Mail list logo
