Re: [GENERAL] Select count with offset returns nothing.
My question is why would you put an offset in a query designed to return a row count without grouping and ordering? Date: Fri, 5 Aug 2011 22:51:24 +1200 Subject: [GENERAL] Select count with offset returns nothing. From: timuc...@gmail.com To: pgsql-general@postgresql.org I am using a library which is emitting SQL like this SELECT COUNT(*) FROM batches LIMIT 15 OFFSET 15 the library fails because on postgres this query returns nothing (not even zero as a result). Presumably it returns some valid value on mysql and other databases. Other than hacking the library is there anything I can do? Oddly enough SELECT count(*) FROM batches LIMIT 15 returns the full count of the table. Presumably the count has to be done on a subquery right? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 9.1 Trigger question
Thank you for the link Merlin. Date: Thu, 10 Mar 2011 08:22:13 -0600 Subject: Re: [GENERAL] 9.1 Trigger question From: mmonc...@gmail.com To: michaelblack75...@hotmail.com CC: pgsql-general@postgresql.org On Wed, Mar 9, 2011 at 8:24 PM, Michael Black michaelblack75...@hotmail.com wrote: The following from 9.1 documentation on triggers SQL allows you to define aliases for the old and new rows or tables for use in the definition of the triggered action (e.g., CREATE TRIGGER ... ON tablename REFERENCING OLD ROW AS somename NEW ROW AS othername ...). Since PostgreSQL allows trigger procedures to be written in any number of user-defined languages, access to the data is handled in a language-specific way. This seems to imply that triggers actually have to reference a function rather than containing the actual code for the trigger to perform. For example the only valid format of a trigger is to CREATE TRIGGER view_insert --- other parameters here --- EXECUTE PROCEDURE view_insert_row(); Instead of the normal way CREATE TRIGGER view_insert --- other parameters here --- AS --- sql functions, conditions and statements --- ; Is my understand in of this correct? If so, how does the other language know the old record from the new? This is correct. In PostgreSQL, the trigger function is always separate from the trigger definition. Procedures written in various languages in PostgreSQL have to wrap an internal API that provides access to various features, querying, etc. Take a look for example how it is exposeed in python: http://www.postgresql.org/docs/9.0/interactive/plpython-trigger.html -- if you wanted to see how that was done you could look at the code for the python language handler. merlin
[GENERAL] 9.1 Trigger question
The following from 9.1 documentation on triggers SQL allows you to define aliases for the old and new rows or tables for use in the definition of the triggered action (e.g., CREATE TRIGGER ... ON tablename REFERENCING OLD ROW AS somename NEW ROW AS othername ...). Since PostgreSQL allows trigger procedures to be written in any number of user-defined languages, access to the data is handled in a language-specific way. This seems to imply that triggers actually have to reference a function rather than containing the actual code for the trigger to perform. For example the only valid format of a trigger is to CREATE TRIGGER view_insert --- other parameters here --- EXECUTE PROCEDURE view_insert_row(); Instead of the normal way CREATE TRIGGER view_insert --- other parameters here --- AS --- sql functions, conditions and statements --- ; Is my understand in of this correct? If so, how does the other language know the old record from the new?
Re: [GENERAL] First production install - general advice
One thing that comes to mind... Have you tested the install process from start to end? Other than that, a week until to go live is a is time to relax, exhale, prop your feet on the desk, and visualize the process thinking of every step, automated and manual, what could happen here and is a resolution in place to get past it. If there is not a resolution and if it is not an easy one to work up, write it down and do it manually, if the issue arises. At this stage of the project, if all the work is done, tested and accepted, there is not really much else that you can do other than relax. To: pgsql-general@postgresql.org Subject: [GENERAL] First production install - general advice Date: Mon, 7 Mar 2011 12:34:19 -0500 From: run...@winning.com I'm going to go live with my first production install of PostgreSQL 9.0 in about a week. I've done a LOT of reading on the internet and I've purchased two very good reference books and actually read them: PostgreSQL 9 Administration Cookbook PostgreSQL 9.0 High Performance I'd like to know if any of you have ever installed a PostgreSQL database for production use and then found something you wish you had done differently after the fact. Maybe your directory naming scheme, your backup strategy, environment variable settings etc. In this last week before we go live I'm hoping to get a few last minute tidbits of information that me help me avoid some common problems. Thank you, Rick
Re: [GENERAL] script errors or PEBKAC?
I would check the order in which things are being created in your process. What I usually do is create all the tables sans indexing or constraints (except primary key). Once the table are done, load the data in to the tables that need to be populated. Then constraints, triggers and then indexes. But, hey, that is just me. One thing, make sure you know your data. I mean if you are adding new (not before used on the data) unique indexes, make sure the loaded data will support that uniqueness. Just 2 cents. Michael From: hawat.thu...@gmail.com To: pgsql-general@postgresql.org Date: Fri, 4 Mar 2011 07:48:04 -0800 I cannot get the script here: https://docs.google.com/leaf?id=0B5hKxkS1VyAxOGMzZjY4ZjktZjZkOS00Zjc3LWExYmEtYTU3ZThjYzZiMjk3hl=en to run correctly. Looking at the output, many, many, errors, it seems to assume tables exist which don't. Is that correct? The script is supposed to create a database, but it seems to assume that the schema is already there and configured? Or, maybe I'm not running it correctly? thanks, Thufir -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Index question
Ok. I have been working with databases a few years but my first real venture in to PostgreSql. I just want a plain simple index regardless if there are duplicates or not. How do I accomplish this in PostgreSql? Michael
[GENERAL] Grant question
Ok. What am I missing here? B_USER is a defined Group Role CREATE ROLE B_USER NOSUPERUSER NOINHERIT NOCREATEDB NOCREATEROLE; GRANT SELECT PRIVILEGES ON b.config_itm TO ROLE B_USER; Nets this --- ERROR: syntax error at or near B_USER LINE 3: TO ROLE B_USER; ^ ** Error ** ERROR: syntax error at or near B_USER SQL state: 42601 Character: 42
Re: [GENERAL] Index question
Thank you for the links. Subject: Re: [GENERAL] Index question From: j...@commandprompt.com To: a...@crankycanuck.ca CC: pgsql-general@postgresql.org Date: Wed, 2 Mar 2011 11:05:58 -0800 On Wed, 2011-03-02 at 13:45 -0500, Andrew Sullivan wrote: On Wed, Mar 02, 2011 at 06:31:57PM +, Michael Black wrote: Ok. I have been working with databases a few years but my first real venture in to PostgreSql. I just want a plain simple index regardless if there are duplicates or not. How do I accomplish this in PostgreSql? CREATE INDEX? Perhaps this would be useful: http://www.postgresql.org/docs/9.0/static/index.html And specifically: http://www.postgresql.org/docs/9.0/static/sql-commands.html JD A -- Andrew Sullivan a...@crankycanuck.ca -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] How to use RETURN TABLE in Postgres 8.4
Actually, since pgsql does not rely on the names but rather the position of the columns returned to fill the returned table, it would be better to use something like CREATE OR REPLACE FUNCTION buggy_procedure() RETURNS TABLE (rv_id INT8, rv_test VARCHAR) AS $$ BEGIN -- @todo hide password RETURN QUERY SELECT id as t_id, test as t_test FROM bug_table ; END; Unless you code that calls this function has the column names coded with in it, you can also access the data returned using an index, or position, to get the values in the returned recordset. lv_id = rs.column(1) *if not a zero based language*. Date: Fri, 3 Jul 2009 17:49:42 +0200 Subject: Re: [GENERAL] How to use RETURN TABLE in Postgres 8.4 From: pavel.steh...@gmail.com To: t...@sss.pgh.pa.us CC: dy...@poczta.onet.pl; pgsql-general@postgresql.org 2009/7/3 Tom Lane t...@sss.pgh.pa.us: Michal Szymanski dy...@poczta.onet.pl writes: CREATE OR REPLACE FUNCTION buggy_procedure() RETURNS TABLE (id INT8, test VARCHAR) AS $$ BEGIN -- @todo hide password RETURN QUERY SELECT id ,test FROM bug_table ; END; $$ LANGUAGE plpgsql STRICT SECURITY DEFINER; Don't use column names in your functions that are the same as variable or parameter names of the function. This is working basically as if you'd written SELECT null,null, because the output parameters are still null when the RETURN QUERY is executed. use qualified names instead RETURN QUERY SELECT b.id, b.test FROM bug_table b; regards Pavel Stehule regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Store derived data or use view?
In addition to the amount of data that will be captured, you will need take in to consideration how often each user will be accessing this data as well as the number of users. For example, if you have 10 users running the query once an hour every hour of the day, you might get away with calculating the aspect each time the data data is requested. But if you have 100 users wanting the data every 15 minutes, you may find it faster to perform the calculations on the insert of the planetary data. Personally, and since you indicated that there will a large amount of data, I would do the calculations on insert. I am not associated with NASA. From: mgai...@hotmail.com To: gvi...@googlemail.com; pgsql-general@postgresql.org Subject: Re: [GENERAL] Store derived data or use view? Date: Fri, 3 Jul 2009 15:46:50 -0400 i just asked NASA the same question I'll post the answer back to the list.. Martin Gainty We can lick gravity, but sometimes the paperwork is overwhelming. - Wehrner Von Braun __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Fri, 3 Jul 2009 18:08:17 +0100 From: gvi...@googlemail.com To: pgsql-general@postgresql.org Subject: [GENERAL] Store derived data or use view? I have a table which stores the absolute longitude of a planetary position, eg: MERCURY --- 157.65 SATURN - 247.65 When 2 planets are a certain distance apart there is an 'aspect', eg. 90 degrees is a square aspect I wish to record these aspects for different user profiles and eventually do searches for users who have the same aspect(s). Would it be better, in terms of search speed/efficiency, to calculate and store the aspect data, eg. Mercury/Saturn square, or should I just store the longitude data and create a view with the calculated aspects? I anticipate a large dataset of users so search speed/efficiency is very important. gvim -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general Insert movie times and more without leaving Hotmail®. See how.
Re: [GENERAL] Looking for advice on database encryption
If the purpose of encrypting the data is just to keep prying eyes from decerning what that data is then a simple encryption can be coded. something like adding 128 or 256, depending on the character set, to each of the chr(value) for each of the characters in the string should work just fine. You could also use a bitwise shift or xor to change the value of each character. If the purpose of encryption is for financial or medica data transmission security, or something of a higher order, you may want to implement a stronger type of security such as SSL or PGP or some other type of public/private key process. You could create a schema that contains views of the data with out the sensitive data and have the users use that schema for their needs, assumes that it basically used to view or report on the data. Just some thoughts. Michael Black Date: Thu, 16 Apr 2009 15:40:12 -0400 From: wmo...@potentialtech.com To: pgsql-general@postgresql.org Subject: [GENERAL] Looking for advice on database encryption What are folks doing to protect sensitive data in their databases? We're running on the assumption that the _really_ sensitive data is too sensitive for us to just trust the front-end programs that connect to it. The decision coming down from on-high is that we need to encrypt certain fields. That's fine, looked at pgcrypto, but found the requirement to use pgp on the command line for key management to be a problem. So we're trying to implement the encryption in the front-end, but the problem we're having is searching on the encrypted fields. Since we have to decrypt each field to search on it, queries that previously took seconds now take minutes (or worse). We've tested a number of cryptographic accelerator products. In case nobody else has tried this, let me give away the ending: none that we've found are any faster than a typical server CPU. So, it's a pretty open-ended question, since we're still pretty open to different approaches, but how are others approaching this problem? The goal here is that if we're going to encrypt the data, it should be encrypted in such a way that if an attacker gets ahold of a dump of the database, they still can't access the data without the passphrases of the individuals who entered the data. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
FW: [GENERAL] [GENEAL] dynamically changing table
From: michaelblack75...@hotmail.com To: gentosa...@gmail.com Subject: RE: [GENERAL] [GENEAL] dynamically changing table Date: Mon, 30 Mar 2009 16:05:52 + The simplest way is to plan for the maximum number of columns that will be required (say 14 - 2 weeks of data assuming that is daily reporting numbers in the columns. You could have only a single data column and in the first record insert the number of columns that need to be processed, and build the data in the method to load an array to simulate a record object for that number. Then process cor the lenghth of the array. Or you could use the Drop table and Create table instead of Delete data and Alter Table. Also by varying the number of columns you have programming considerations in addition. The the input and process meths will need to check the meta data to determine how many columns it is dealing with. Those are just to options that come to mind. Michael Date: Mon, 30 Mar 2009 17:39:19 +0200 Subject: [GENERAL] [GENEAL] dynamically changing table From: gentosa...@gmail.com To: pgsql-general@postgresql.org Hi, In the next project I'm going to have a number of colums in my tables, but I don't know how many, they change. They all use integers as datatype though.. One day, I get 2 new columns, a week later I loose one column, and so on in a random pattern. I will most likely have a few million rows of data so I just wonder if there are any problems with running alter table x add column . or alter table x drop column . Adding a column, will it place data far away on the disc so that select * from x where id=y will result in not quite optimal performance since it has to fetch columns from a lot of different places? Will deleting a column result in a lot of empty space that will anoy me later on? Are there any other clever solutions of this problem? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] ALTER TABLE and adding FK Constraints - Assistance Requested
First, I am relatively new to postgres, but have been using database (design not administering) for about 20 years (you would think that I could figure this out - lol). At an rate, I am trying to create tables that have forgein keys via a script. What happens is if the table that is referred to in the forgeing key does not exist, the table fails to create. Undertandable. So what I need to do is create all the tables and then go back and alter the tables by adding the forgein key constraint. I got that. But what I am looking for is the correct syntax to add the forgein key constrant. I have tried ALTER TABLE name CONSTRANT constraint description and ALTER TABLE name ADD CONSTRANT constraint description. But both fail. Yes I am being lazy. I should go through the script and create the tables that are referenced first then the ones with the forgein key. But I also need to know this in the even the schema changes in the future and more constratins are necessary. I have looked at the ALTER TABLE syntax on postgres but it refers back to the CREATE TABLE function. Michael Date: Sun, 29 Mar 2009 13:58:30 +0200 Subject: [GENERAL] Fwd: concatenate and use as field From: raf.n...@gmail.com To: pgsql-general@postgresql.org Hi, i have a character varying variable and i concatenate with some other variable, using the '||' operator. the result of this concatenation should be the name of a column in my table. however i don't know how to tell that this new concatenated string is a column name. how to do it ? thanks. in fact i'm trying to do the following thing: select id, theme_ || $1 from themes; and based on the parameter my stored procedure has received, it should create something like that: select id, theme_eng from themes; if $1 = 'eng' I think i'm a good way, but i still have a problem with the performance. when i call my stored procedure, it can take 0.1 s to 3.5 seconds to execute it on local computer. How can i improve it ? here is my stored procedure: CREATE OR REPLACE FUNCTION sewe.get_category_and_amount(character varying) RETURNS SETOF category_amount AS $BODY$ DECLARE inLanguage ALIAS FOR $1; outCategoryAndAmount category_amount; Lang character varying :=''; BEGIN IF inLanguage = null OR inLanguage = '' THEN Lang := 'eng'; ELSE Lang := inLanguage; END IF; FOR outCategoryAndAmount IN EXECUTE 'SELECT id, theme_name_' || Lang || ' FROM themes WHERE parent_theme IS NULL ORDER BY theme_name_' || Lang || ' ASC' LOOP RETURN NEXT outCategoryAndAmount; END LOOP; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE COST 100 ROWS 1000;
Re: [GENERAL] ALTER TABLE and adding FK Constraints - Assistance No longer needed
Thanks to all that responded. I got it figured out. The one I was testing did not have the associated table created yet (error message did not point me to a solution). Created the referenced table and it worked like a chump, er champ. Michael From: michaelblack75...@hotmail.com To: pgsql-general@postgresql.org Subject: [GENERAL] ALTER TABLE and adding FK Constraints - Assistance Requested Date: Sun, 29 Mar 2009 15:04:28 + First, I am relatively new to postgres, but have been using database (design not administering) for about 20 years (you would think that I could figure this out - lol). At an rate, I am trying to create tables that have forgein keys via a script. What happens is if the table that is referred to in the forgeing key does not exist, the table fails to create. Undertandable. So what I need to do is create all the tables and then go back and alter the tables by adding the forgein key constraint. I got that. But what I am looking for is the correct syntax to add the forgein key constrant. I have tried ALTER TABLE name CONSTRANT constraint description and ALTER TABLE name ADD CONSTRANT constraint description. But both fail. Yes I am being lazy. I should go through the script and create the tables that are referenced first then the ones with the forgein key. But I also need to know this in the even the schema changes in the future and more constratins are necessary. I have looked at the ALTER TABLE syntax on postgres but it refers back to the CREATE TABLE function. Michael Date: Sun, 29 Mar 2009 13:58:30 +0200 Subject: [GENERAL] Fwd: concatenate and use as field From: raf.n...@gmail.com To: pgsql-general@postgresql.org Hi, i have a character varying variable and i concatenate with some other variable, using the '||' operator. the result of this concatenation should be the name of a column in my table. however i don't know how to tell that this new concatenated string is a column name. how to do it ? thanks. in fact i'm trying to do the following thing: select id, theme_ || $1 from themes; and based on the parameter my stored procedure has received, it should create something like that: select id, theme_eng from themes; if $1 = 'eng' I think i'm a good way, but i still have a problem with the performance. when i call my stored procedure, it can take 0.1 s to 3.5 seconds to execute it on local computer. How can i improve it ? here is my stored procedure: CREATE OR REPLACE FUNCTION sewe.get_category_and_amount(character varying) RETURNS SETOF category_amount AS $BODY$ DECLARE inLanguage ALIAS FOR $1; outCategoryAndAmount category_amount; Lang character varying :=''; BEGIN IF inLanguage = null OR inLanguage = '' THEN Lang := 'eng'; ELSE Lang := inLanguage; END IF; FOR outCategoryAndAmount IN EXECUTE 'SELECT id, theme_name_' || Lang || ' FROM themes WHERE parent_theme IS NULL ORDER BY theme_name_' || Lang || ' ASC' LOOP RETURN NEXT outCategoryAndAmount; END LOOP; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE COST 100 ROWS 1000;
Re: [GENERAL] Chart of Accounts
James,
It is not good practice to delete an account with out first transfering the
amount in that account to another account. You will also need to make sure the
account has a zero balance before deleting it. You will also need to log the
transactions if funds are moved between accounts with a reason why they were
transfred.
To me a intelegent accounting system means that when you make an entry in one
account, the system automatically makes a corresponding entry on the other side
of the equal sign. Example credit Office Supplies the system debits Cash On
Hand (or what ever account is used to pay for office supplies).
The issue on the update, try using an if statement like
If new.amt != old.amt Then
Do Amount Changes that you already have in place
End if
The database should then go ahead an update the parent wtihout an issues. If
that does not work create a function that drops the trigger, update the table
and then creates the trigger. I am sure that this type of change (moving
accounts) will not be a common thing once the COA has been set up and in use
for a while.
HTH.
Michael
Date: Mon, 10 Nov 2008 05:24:03 +0100 From: [EMAIL PROTECTED] To: [EMAIL
PROTECTED] Subject: Re: [GENERAL] Chart of Accounts CC:
pgsql-general@postgresql.org Hi James, There is some my publications
about SART AML System based on banking General Ledger (OLAP Data Warehouse
and Chart of Accounts as dimension with 60 000+ items) - may be helpful.
http://www.analyticsql.org/documentation.html
http://www.analyticsql.org/files/AITM-MoneyLaundering.pdf Regards, Blazej
Oleszkiewicz 2008/10/12 James Hitz [EMAIL PROTECTED]: Dear All,
I have just started experimenting with PGSQL, with a view to migrate from the
SQL server I use currently. I am trying to implement an intelligent Chart
of Accounts for an accounting program. The following is long-winded but
please bear with me: I have a table coa (chart of accounts) with the
following schema CREATE TABLE coa( coa_id serial not null,
parent_id int not null default 0, account_name text not null, amt money
default 0, primary key(coa_id) ); After populating the database
with basic accounts it resembles this (the hierarchy is mine): coa_id,
parent_id, account_name, amt 0, -1, 'Chart of Accounts', 0.00 1, 0,
'Assets', 0.00 5, 1, 'Fixed Assets', 0.00 6, 5, 'Motor Van', 0.00
--truncated --- 2, 0, 'Liabilities', 0.00 3, 0, 'Income', 0.00 4, 0,
'Expenses', 0.00 So far, so good. I would like it so that if the amt of
a a child account changes, the parent account is updated, if a child account
is deleted, the amount is reduced off of the parent account etc. I have
managed to achieve this using the following trigger functions: CREATE
OR REPLACE FUNCTION public.coa_del_amt() RETURNS trigger AS $body$
begin update coa set amt = amt - old.amt where coa_id = old.parent_id;
return old; end; $body$ LANGUAGE 'plpgsql' --
CREATE OR REPLACE FUNCTION public.coa_ins_amt() RETURNS trigger AS
$body$ begin UPDATE coa SET amt = amt + new.amt WHERE coa_id =
new.parent_id; return new; end; $body$ LANGUAGE 'plpgsql'
CREATE OR REPLACE FUNCTION public.coa_upd_amt() RETURNS
trigger AS $body$ begin IF new.parent_id = old.parent_id THEN
UPDATE coa SET amt = amt + (new.amt - old.amt) WHERE coa_id =
new.parent_id; ELSE UPDATE coa SET amt = amt - old.amt WHERE
parent_id = old.parent_id; UPDATE coa SET amt = amt + new.amt WHERE
parent_id = new.parent_id; END IF; RETURN new; end; $body$
LANGUAGE 'plpgsql' These have been bound to the
respective ROW before triggers. And they work as expected upto a certain
extent. eg assigning a value to 'Motor Van' updates the relevant parent
accounts: UPDATE coa SET amt = 4000 WHERE coa_id = 6; The problem
comes about when one wants to change the parent account for a sub account eg,
assuming in the example above that 'Motor Van' was a liability, attempting to
change its parent_id from 1 to 2 is erronous and somewhat interesting because
the amt for all related accounts are reset to unpredictible values, AND the
parent_id does not change anyway. The problem lies squarely in the
function coa_upd_amt(). Any ideas. Thank you. --
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To
make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general -- Sent via
pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to
your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Relation not gfound in view Error
I created two tables populated both with valid data including forgien key values. I create a view that uses both of these tables in a view that. When I select from the view, I get this error ERROR: relation vwsinglelevellist does not existSQL state: 42P01 But when I run the defination as a simple select statement, I do not get an error. Any ideas? TIA Michael
[GENERAL] Alternate locations
I have attempted to configure PostgreSQL as described on the website to use a different location to no avail. Any hints, suggestions or instructions would be appreciated. RedHat 6.1 and the version of PostgreSQL that came with it. Michael Black
