Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ab8E1-0003uV-Aq for pgsql-sql@arkaria.postgresql.org; Wed, 02 Mar 2016 14:58:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ab8E0-00017C-QS for pgsql-sql@arkaria.postgresql.org; Wed, 02 Mar 2016 14:58:04 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ab8Dz-00016Q-Nt for pgsql-sql@postgresql.org; Wed, 02 Mar 2016 14:58:04 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ab8Dx-00018T-1b for pgsql-sql@postgresql.org; Wed, 02 Mar 2016 14:58:02 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8BBD320656 for ; Wed, 2 Mar 2016 09:57:59 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 02 Mar 2016 09:57:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Ia3V5PD8HlqA2wRQOOdhcsBKG70=; b=G7TYN3 IArKid7xXdCtAFs95ie4+7A5PJv204n6P3SH82aTJN39QD7NgfLFe5ZF0kRmCGw6 uSKV+O+6lUUhQVHn4H46nu1clZE5s3hjty73x8pHdjy6jGTioZsnqusN4Js/BooI Y7XCzuce8yz1m0acB9Xe/RvVQMXwCoRmkxuW4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Ia3V5PD8HlqA2wR QOOdhcsBKG70=; b=JI1CkEU4XT8kHKFiAhwgvcrwrpOcCKVdZCkV4hzHt9gVmcm iGidw5myBtvT8m+ujKV4G+P1yLiGoRmQVxKpC8H5Lt6Ojl/vqu35MDKqdAhaOuNT FaXyD0VwrEvd/5cyjKjS+q9H5Y3smNV70DIa5546LgkhXRNgF2sYUaYtKV+I= X-Sasl-enc: X4df6Xc54TJ0b9uMHBtddxI+tpbnZ4bvLc+BFQzAjODf 1456930679 Received: from [192.168.1.2] (174-21-70-246.tukw.qwest.net [174.21.70.246]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A636680106; Wed, 2 Mar 2016 09:57:58 -0500 (EST) Subject: Re: Query about foreign key details for php framework To: David Binney , pgsql-sql@postgresql.org References: <56CFA136.4000508@aklaver.com> <56CFA4E1.8040204@aklaver.com> <56CFC24A.6030508@aklaver.com> <56D06C02.5040107@aklaver.com> <56D0C4B8.7020200@aklaver.com> <56D1BEA6.5020707@aklaver.com> <56D45C99.4060008@aklaver.com> From: Adrian Klaver Message-ID: <56D6FF29.1000309@aklaver.com> Date: Wed, 2 Mar 2016 06:56:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org On 03/01/2016 05:38 PM, David Binney wrote: > Hey Adrian, > > Yes, that is the problem of not being able to join on the table name, to > obtain these any fields from that table. Also, it is for a framework > which will be managing constrains/rules/adds/deletes etc. , so needs to > know the constrain details against each table. Short version: http://www.postgresql.org/docs/9.5/interactive/catalog-pg-constraint.html SELECT * FROM pg_constraint WHERE conrelid = 'some_table'::regclass AND contype='f'; > > On Tue, 1 Mar 2016 at 00:59 Adrian Klaver > wrote: > > On 02/28/2016 03:42 PM, David Binney wrote: > > Hey adrian, > > > > rc.constraint_name AS name, > > tc.constraint_type AS type, > > kcu.column_name, > > rc.match_option AS match_type, > > rc.update_rule AS on_update, > > rc.delete_rule AS on_delete, > > kcu.table_name AS references_table, > > kcu.column_name AS references_field, > > kcu.ordinal_position > > > > Those are the columns that i need as a minimum, but as you know > they are > > all easy apart from the rules "on update" from the "RC" table. > > I am not following, update_rule is just a field in > information_schema.referential_constraints, how is it any harder then > delete_rule? > > The issue from what I understand is that > information_schema.referential_constraints does not have a table_name > field to constrain the information to a particular table. This leads > back to the overriding question, what is the purpose of the query? I > suspect it for use by the framework to set up attributes of a model > based on a table, is that correct? > > > > > I did start having a crack at the catalog tables but that is pretty > > complicated. > > > > On Sun, 28 Feb 2016 at 01:21 Adrian Klaver > > > >> wrote: > > > > On 02/26/2016 08:29 PM, David Binney wrote: > > > Hey adrian, > > > > > > You are correct that the distinct will chomp the resultset > down > > to the > > > correct count, I am just concerned that there will be > cases where it > > > might not be accurate between the "rc" and the "kcu" joins as > > there is > > > no table reference. I have simplified the query right down to > > just the > > > join that i am unsure about. You can see below that as > soon as i > > add the > > > rc.unique_constraint_name, the distinct is no longer returning > > one row. > > > In this case its fine because the rc values are the same > and would > > > distinct away, but there might be a case where they are > diferent > > and you > > > would have two rows and not know which values are correct? > > > > > > > Well it comes down to the question that was asked several times > > upstream: > > > > what is the information you want to see? > > > > I am not talking about a query, but a description of what > attributes you > > want on what database objects. > > > > Also given, from previous post: > > > > "I am a little in the dark as well since this is just a > broken piece of > > ORM i am attempting to fix, in the framework." > > > > Is this not something that should be discussed with the framework > > developers, or are we already doing that:)? > > > > > > > > -- > > Adrian Klaver > > adrian.klaver@aklaver.com > > > > > > -- > > Cheers David Binney > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > > -- > Cheers David Binney -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql