[SQL] connectby queries
Hi, How do I write hierarchical queries in postgresql, which I would write using ‘connectby’ in oracle?? Thanx in adv Chandan
Re: [SQL] (non)zero function
Hi, On Sun, 27 Mar 2005, Enrico Weigelt wrote: Hi folks, is there an function returning true if the argument is null or zero (just to make some queries more concise). Of course its trivial to implement as SQL function, but if postgresql already provides such a function, I would prefer using it. Lookup the documentation on COALESCE() http://www.postgresql.org/docs/current/static/functions-conditional.html 9.13.2. COALESCE Greetings Christian -- Christian Kratzer [EMAIL PROTECTED] CK Software GmbHhttp://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] [HACKERS] Executing Anonymous Blocks
On Mon, Mar 28, 2005 at 12:27:18PM +0500, imad wrote: > I want to know is there any way to execute an anonymous PL/pgSQL block > in PostgreSQL. No, there isn't. -- Alvaro Herrera (<[EMAIL PROTECTED]>) Al principio era UNIX, y UNIX habló y dijo: "Hello world\n". No dijo "Hello New Jersey\n", ni "Hello USA\n". ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] connectby queries
On Mon, Mar 28, 2005 at 02:02:32PM +0530, Chandan_Kumaraiah wrote: > > How do I write hierarchical queries in postgresql, which I would write > using 'connectby' in oracle?? The contrib/tablefunc module has a connectby() function -- does it do what you want? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[SQL] Postgres 7.3 migrate to 8.0 date problems.
Hi, We were upgrading from postgres 7.3 -> 8.0 and having a little problems importing dates from some of our data sources. Say we have a date like '2004-17-05'. In postgres 7.3, postgres would intrept this as Year Day Month automatically. In the documentation, from postgres 7.4 on this has to be specified in the Datestyle option and YDM is not an option. Other data we have is coming in on the YMD formate which would be more expected. I realize that this change is better for data integrity, however we have alot of legacy systems where being able to mimic the 7.3 behaviour would be desireable. Any ideas? -Tom Seeber Edison Schools ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Postgres 7.3 migrate to 8.0 date problems.
On Mon, 2005-03-28 at 13:44, Thomas Seeber wrote: > Hi, > > We were upgrading from postgres 7.3 -> 8.0 and having a little > problems importing dates from some of our data sources. Say we have a > date like '2004-17-05'. In postgres 7.3, postgres would intrept this > as Year Day Month automatically. In the documentation, from postgres > 7.4 on this has to be specified in the Datestyle option and YDM is not > an option. Other data we have is coming in on the YMD formate which > would be more expected. I realize that this change is better for data > integrity, however we have alot of legacy systems where being able to > mimic the 7.3 behaviour would be desireable. Any ideas? Fix the data? I had to write a lot of scripts to keep dates like that OUT of my last PostgreSQL installation, which was running 7.2 Which is why, as the guy who whinged and moaned until this behavioural change was made, I feel for you, but honestly, the lackadaisical manner of handing that particular format (-DD-MM) never really seemed right even to the people who fought me on the idea of changing the default behaviour of DD/MM/ versus MM/DD/. While the US uses MM/DD/ and Europe uses DD/MM/, and there may be some arguments for handling a sloppy version of one of those, computer folk (and the government) who want easily ordered dates use -MM-DD, I've never seen a good argument made for the usage of -DD-MM before. Are you sure that the other dates in your data set are what you think they are? Because if the two numbers are both <=12, then you'll get one "date" and if the wrong one is >12 you'll get another. That can't be good. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] cost of CREATE VIEW ... AS SELECT DISTINCT
Hello, How expensive would it be to maintain the following VIEW: CREATE VIEW origin AS SELECT DISTINCT origin FROM transaktion if there is in index on transaktion.origin; the table transaktion has thousands of records and there are only a few distinct origin? -- Regards/Gruß, Tarlika Elisabeth Schmitz ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [SQL] cost of CREATE VIEW ... AS SELECT DISTINCT
On Mon, 2005-03-28 at 15:43, T E Schmitz wrote: > Hello, > How expensive would it be to maintain the following VIEW: > > CREATE VIEW origin AS SELECT DISTINCT origin FROM transaktion > > if there is in index on transaktion.origin; the table transaktion has > thousands of records and there are only a few distinct origin? The cost will only be encurred when running the view. if you want materialized views (which WOULD have maintenance costs) you'll have to do a google search for postgresql materialized views and implement them by hand, so to speak. The cost of executing that view should be the same as the cost of running the query by hand. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
