Re: [GENERAL] [JDBC] SQLData user-defined-types and getObject()
On Sat, 7 Jan 2006, Assad Jarrahian wrote: I am quite confused (PLEASE PLEASE Help), I cannot find anything on the web). I read that you can declare a class that implements SQLData (in this case I set up a class called Complex from the /src/tutorial datatype that mimics the user-defined datatype in the db) and then set the mapping appropriately (see below). This is possible according to the JDBC spec, but the postgresql driver does not implement it. At the moment your only option is to have your class implement org.postgresql.util.PGobject and register it using a pg specific method. This is fine for a true user defined type, but it certainly isn't ideal for a composite type because it requires the type creator to handle all of the fields himself. There isn't much documentation on PGobject implementations either, but the javadoc and source code will point you in the right direction. http://jdbc.postgresql.org/documentation/publicapi/org/postgresql/util/PGobject.html Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Arrays and Performance
Sorry for the duplicate post! My first post was stalled and my mail server down for a day or so. I will reply to your original posts. Regards, Marc Philipp ---(end of broadcast)--- TIP 1: 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: [GENERAL] Arrays and Performance
No, we don't get deadlock errors, but when running a vacuum and another process writing into the database there progress will stop at some point and nothing happens until one process is being killed. I think we used to vacuum every two nights and did a full vacuum once a week. Regards, Marc Philipp ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL Arrays and Performance
How large are the arrays? PG is definitely not designed to do well with very large arrays (say more than a couple hundred elements). You should reconsider your data design if you find yourself trying to do that At the moment, the arrays are not larger than 200 entries. But there is not upper bound for their size. Regards, Marc Philipp ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] PostgreSQL Arrays and Performance
This sounds like it has more to do with inadequate freespace map settings than use of arrays. Every update creates a dead tuple, and if it is large (because the array is large) and leaked (because you have no room in your freespace map), that would explain a rapidly increasing database size. Can you tell me more about free-space map settings? What exactly is the free-space map? The information in the documentation is not very helpful. How can dead tuples leak? Regards, Marc Philipp ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Installing Postgres 8.1 on Windows Server 2003 R2
Has anyone tried to install Postgres on Windows Sever 2003 version R2? R2 is actually shipping as a 'new' Microsoft product- it's basically an interim update to Windows Server ( http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.msp x http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.mspx ). Not that I know of, but it's been on my list of things to try :-) I've installed Postgres on other versions of Windows with no problem, so I'm afraid that the error I'm seeing now is related to some great new 'feature' from Microsoft. Here's the error message returned by Postgres before install begins- Error binding the test network socket: 10013 That error means: An attempt was made to access a socket in a way forbidden by its access permissions. Microsoft Antispyware has been turned off (closed the application) and Windows Firewall isn't running. There's no other AV or firewall software on this system yet. Any ideas on what might be going on? It certainly *sounds* a lot like a firewall issue :-) I'd double and triple check that. We've seen it several times before and it has AFAIK always been a firewall. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] COPY to
Angshu Kar schrieb: Thanks Andreas. But how can I run this from the pgAdmin III Query tool in a WinXP m/c? You dont. There is the function for saving query data to file already built in. Just press the button (documentation or tooltips tell you) and select the format of your csv in the requester that appears. ---(end of broadcast)--- TIP 1: 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
[GENERAL] autocommit to off
Help me please! I need change autocommit to off in fedora core 3 in postgresql.conf i don´t know. How can i do? Thanks a lot Marcelo Lima. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze ---(end of broadcast)--- TIP 1: 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
[GENERAL] PGError: server closed the connection unexpectedly
Hello list, I've been working a bit today to resolve the error I'm seeing mentioned in the title, and I was hoping you might have some insight. I've managed to semi-reliably reproduce this based on two different tasks: - a pg_dumpall from my backup server will throw this, but not always on the same database. Sometimes it seems to get 'stuck' on one, but later if I try it again it'll throw the error on a different DB. The pg_dumpall appears to work perfectly when run locally. - A unit test for a Rails app I'm developing will consistently throw this error, though oddly I can run the problem statement in psql, over the network, without problem. My biggest problem is the lack of any real error message on the server. I don't see anything wrong in the system logs, and there's no core file in the /var/postgresql directory. I did a 'vacuumdb -afz' just as a shot in the dark, without affect. Pretty much all I see in the logs is this: USER%DB x.y.z.a(51478) 487LOG: unexpected EOF on client connection Googling turned up a few reports suggesting bad hardware, or corrupted indexes, but I don't think that's the case here. Any starting points or ideas would be greatly appreciated. Basic server info: - Less than 3 months old - OpenBSD 3.8, patched fully, x86 w/ a P4 - 2G of Ram, ~1.5G free usually - /var/postgresql partition has about 8G free, and is backed by a AMI hardware raid-1 array. - PostgreSQL version 8.0.3 on server and clients, built locally from OpenBSD ports - ruby-postgres adapter version 0.7.1 used in the rails project Special OS Config bits: - kern.seminfo sysctl tree: kern.seminfo.semmni=256 kern.seminfo.semmns=2048 kern.seminfo.semmnu=30 kern.seminfo.semmsl=60 kern.seminfo.semopm=100 kern.seminfo.semume=10 kern.seminfo.semusz=100 kern.seminfo.semvmx=32767 kern.seminfo.semaem=16384 - Bits from _postgresql's ulimit: $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes)8192 lockedmem(kbytes)635424 memory(kbytes) 1905136 nofiles(descriptors) 768 processes532 - postgresql.conf changes: max_connections = 200 syslog_facility = 'LOCAL0' syslog_ident = 'postgres' log_duration = true stats_start_collector = true stats_command_string = false stats_block_level = false stats_row_level = false Thanks in advance! -- Dave Steinberg http://www.geekisp.com/ http://www.steinbergcomputing.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Suse Linux 10.0
On Thursday 05 January 2006 10:57, Peter Eisentraut wrote: Am Donnerstag, 5. Januar 2006 21:15 schrieb Joseph M. Day: Has anyone been able to get the latest version of Postgres working on Suse 10.0 ? I just switched form Fedora and realized that this version is not specifically supported. Get it here: ftp://ftp.suse.com/pub/people/max/postgresql ---(end of broadcast)--- TIP 1: 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 I can't get this to add as an installation source: Server Name: ftp.suse.com Directory on Server:pub/people/max/postgresql/postgresql-8.1.1/10.0-i386 I've tried with and without forward slashes at the beginning and end of Server Name and Directory on Server. I tried adding as FTP and HTTP. I get this error: ERROR(InstSrc:E_noinstsrc_on_media) Any idea what the problem is? Thanks, Jerome ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] How to search?
Thanks, Mike ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] (Select *) vs. (Select id) from table.
Mike wrote: Hi, I am trying to make a website where scalability matters. In my quest to make my website more scalable I broke down the following SQL statement: select * from customers limit 100 to: select id, updated_date from customers limit 100 Then my application would check it's cache to see if it has those records available and will hit the database with consequent: select * from customers where id = 4 or id = 9 or id = 19 Am I really speeding things up by breaking down the SQL statements to what's necessary? or is it faster to get everything right at once! Well, first, it's never really a good idea to use SELECT * FROM in a production application, against a table. Tables can (and do) change from one release to another, and if the layout of the table changes, you could be looking at having to rewrite your code, especially if it relied on the order of the columns in the tables. It's always better to specify the columns that you're looking for, since existing columns should (at least in theory on a production DB) remain present, though their order can change sometimes, depending on what the DBA does. :) Secondly, as far as making your queries more efficient, the only way that you can really do that is to determine actually how long the queries are taking. This is relative to the size of the database in rows, and of course, the data that you're querying against, whether a table scan is necessary, and all of that. This is the process of optimizing queries. For a small table, it can be faster sometimes to just pull all of the records at once (for example, if they're all within a single page). However, if you're pulling from a large DB, it will be faster to use smaller queries against it, using well-placed indexes. Also, you may wish to consider using views if you really like using * with SELECT... Since this way, you can just depreciate a view and start using a new one if the underlying columns are changed. :) Also, if you use views, you can optimize the view's query when it comes time to change it, which mess less messing around in the application code, especially if it is a frequently used query. HTH, Mike ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Suse Linux 10.0
if i were you i'd try to compile, it's better way 2006/6/2, Jerome Lyles [EMAIL PROTECTED]: On Thursday 05 January 2006 10:57, Peter Eisentraut wrote: Am Donnerstag, 5. Januar 2006 21:15 schrieb Joseph M. Day: Has anyone been able to get the latest version of Postgres working on Suse 10.0 ? I just switched form Fedora and realized that this version is not specifically supported. Get it here: ftp://ftp.suse.com/pub/people/max/postgresql ---(end of broadcast)--- TIP 1: 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 I can't get this to add as an installation source: Server Name: ftp.suse.com Directory on Server:pub/people/max/postgresql/postgresql-8.1.1/10.0-i386 I've tried with and without forward slashes at the beginning and end of Server Name and Directory on Server. I tried adding as FTP and HTTP. I get this error: ERROR(InstSrc:E_noinstsrc_on_media) Any idea what the problem is? Thanks, Jerome ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Atentamente, .~. ( 0 0 ) Moisés Alberto Lindo Gutarra / V \ Asesor - Desarrollador Java / Open Source // \\ TUMI Solutions S.A.C. /(( _))\ Cel: 97366260 Trab: 3481104 oo0 0oo MSN: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] COPY to
Got it. Thanks a ton Tino... On 1/8/06, Tino Wildenhain [EMAIL PROTECTED] wrote: Angshu Kar schrieb: Thanks Andreas. But how can I run this from the pgAdmin III Query tool in a WinXP m/c? You dont. There is the function for saving query data to filealready built in. Just press the button (documentation or tooltipstell you) and select the format of your csv in the requesterthat appears. -- Ignore the impossible but honor it ...The only enviable second position is success, since failure always comes first...
Re: [GENERAL] Suse Linux 10.0
Jerome Lyles wrote: On Thursday 05 January 2006 10:57, Peter Eisentraut wrote: Am Donnerstag, 5. Januar 2006 21:15 schrieb Joseph M. Day: Has anyone been able to get the latest version of Postgres working on Suse 10.0 ? I just switched form Fedora and realized that this version is not specifically supported. Get it here: ftp://ftp.suse.com/pub/people/max/postgresql ---(end of broadcast)--- TIP 1: 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 I can't get this to add as an installation source: Server Name: ftp.suse.com Directory on Server:pub/people/max/postgresql/postgresql-8.1.1/10.0-i386 I've tried with and without forward slashes at the beginning and end of Server Name and Directory on Server. I tried adding as FTP and HTTP. I get this error: ERROR(InstSrc:E_noinstsrc_on_media) Any idea what the problem is? Thanks, Jerome Have you tried to just ftp the rpms down and install them that way, either through rpm or YaST? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] (Select *) vs. (Select id) from table.
Michael Trausch [EMAIL PROTECTED] writes: Well, first, it's never really a good idea to use SELECT * FROM in a production application, against a table. Tables can (and do) change from one release to another, and if the layout of the table changes, you could be looking at having to rewrite your code, especially if it relied on the order of the columns in the tables. Wouldn't it be more logical to say it's never a good idea to depend on the order of the columns in the tables then? It's always better to specify the columns that you're looking for, since existing columns should (at least in theory on a production DB) remain present, though their order can change sometimes, depending on what the DBA does. :) And then when new columns are added (or existing columns removed as you point out) what would have to happen to your code? Hint, you used the word above... This particular piece of dogma dates back to the days under Oracle when SELECT * actively broke. If you changed the column you had to recompile the code in question or else you got strange errors or crashes. The *only* way to refer to columns was by position. These days any reasonable driver allows you to use the column names to refer to columns, and application code often has multiple levels of complexity. The layer handling the query often has no idea which columns will be used by later layers. If you hard code the list of columns at each layer then you have to rewrite lots of code when you add a column or change a datatype. -- greg ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] (Select *) vs. (Select id) from table.
On Saturday 07 January 2006 13:50, Michael Trausch wrote: Mike wrote: Hi, I am trying to make a website where scalability matters. In my quest to make my website more scalable I broke down the following SQL statement: select * from customers limit 100 to: select id, updated_date from customers limit 100 Then my application would check it's cache to see if it has those records available and will hit the database with consequent: select * from customers where id = 4 or id = 9 or id = 19 Am I really speeding things up by breaking down the SQL statements to what's necessary? or is it faster to get everything right at once! Well, first, it's never really a good idea to use SELECT * FROM in a production application, against a table. Tables can (and do) change from one release to another, and if the layout of the table changes, you could be looking at having to rewrite your code, especially if it relied on the order of the columns in the tables. It's always better to specify the columns that you're looking for, since existing columns should (at least in theory on a production DB) remain present, though their order can change sometimes, depending on what the DBA does. :) Secondly, as far as making your queries more efficient, the only way that you can really do that is to determine actually how long the queries are taking. This is relative to the size of the database in rows, and of course, the data that you're querying against, whether a table scan is necessary, and all of that. This is the process of optimizing queries. For a small table, it can be faster sometimes to just pull all of the records at once (for example, if they're all within a single page). However, if you're pulling from a large DB, it will be faster to use smaller queries against it, using well-placed indexes. Also, you may wish to consider using views if you really like using * with SELECT... Since this way, you can just depreciate a view and start using a new one if the underlying columns are changed. :) Also, if you use views, you can optimize the view's query when it comes time to change it, which mess less messing around in the application code, especially if it is a frequently used query. HTH, Mike If your application uses a kind of mapping algorithm that is based on the information schema you can use select * without a risk. I'd say a select * is slightly slower than a column name based select, simply because you transfer more information to the application. The time the DB needs to find the record should be the same since the record has to be found before the resultset is assembled. I.e. my application uses an object-relational mapper and returns an object to the application. The object is assembled using the information schema and the columns asked for - if any are asked for specifically. Therefor my app does a lot of select *'s, but it won't break if I add, change or delete columns. It doesn't even break if I rename a column. If you don't use something like that I'd go with the better approach of selecting by column name. The only time when this is considerably slower is while you program the queries (more typing :-) ). Views are the way to go when you know there's going to be changes. Views allow you to define the API your application relies on. Rules allow you to make the view writeable, so you can effectively hide the layout of your database which is allways a good idea. UC -- Open Source Solutions 4U, LLC 1618 Kelly St Phone: +1 707 568 3056 Santa Rosa, CA 95401 Cell: +1 650 302 2405 United States Fax:+1 707 568 6416 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Suse Linux 10.0
On Thu, 2006-06-01 at 23:10 -1000, Jerome Lyles wrote: On Thursday 05 January 2006 10:57, Peter Eisentraut wrote: Am Donnerstag, 5. Januar 2006 21:15 schrieb Joseph M. Day: Has anyone been able to get the latest version of Postgres working on Suse 10.0 ? I just switched form Fedora and realized that this version is not specifically supported. Get it here: ftp://ftp.suse.com/pub/people/max/postgresql ---(end of broadcast)--- TIP 1: 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 I can't get this to add as an installation source: Server Name: ftp.suse.com Directory on Server:pub/people/max/postgresql/postgresql-8.1.1/10.0-i386 I've tried with and without forward slashes at the beginning and end of Server Name and Directory on Server. I tried adding as FTP and HTTP. I get this error: ERROR(InstSrc:E_noinstsrc_on_media) Any idea what the problem is? Thanks, Jerome ---(end of broadcast)--- TIP 6: explain analyze is your friend I downloaded the file locally and then added that folder as a local source in YAST. This probably the better way to do it. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] (Select *) vs. (Select id) from table.
The time the DB needs to find the record should be the same since the record has to be found before the resultset is assembled. What if the query can be satisfied from an index? I don't know if PostgreSQL has this kind of optimization or not. But in the original example: select id, updated_date from customers limit 100 Sybase, for instance, would not use table pages at all if there were an index covering id updated_date. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 665-7007 voice ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] (Select *) vs. (Select id) from table.
Scott Ribe [EMAIL PROTECTED] writes: The time the DB needs to find the record should be the same since the record has to be found before the resultset is assembled. What if the query can be satisfied from an index? I don't know if PostgreSQL has this kind of optimization or not. Nope. Tuple visibility isn't stored in indexes, so it still has to visit the heap to see if a row is visible to your transaction. -Doug ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Installing Postgres 8.1 on Windows Server 2003 R2
That's what I was afraid of... it's a new install of Win Server 2003 R2, so I can rule out any third party firewall. Windows Firewall isNOT installed. And I've installedPostgres on a Windows XP boxbehind the same router, so it's not a router-firewall issue. It's probably a new R2 feature,I'llping someone at Microsoft because Idon'thave a clue at this point what the problem is... Jon On 1/8/06, Magnus Hagander [EMAIL PROTECTED] wrote: Has anyone tried to install Postgres on Windows Sever 2003 version R2?R2 is actually shipping as a 'new' Microsoft product- it's basically an interim update to Windows Server ( http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.msp x http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.mspx ).Not that I know of, but it's been on my list of things to try :-) I've installed Postgres on other versions of Windows with no problem, so I'm afraid that the error I'm seeing now is related to some great new 'feature' from Microsoft.Here's the error message returned by Postgres before install begins- Error binding the test network socket: 10013That error means: An attempt was made to access a socket in a wayforbidden by its access permissions. Microsoft Antispyware has been turned off (closed the application) and Windows Firewall isn't running.There's no other AV or firewall software on this system yet. Any ideas on what might be going on?It certainly *sounds* a lot like a firewall issue :-) I'd double and triple check that. We've seen it several times before and it has AFAIKalways been a firewall.//Magnus
[GENERAL] Functions as a Security Layer
Functions, with some databases, are used as security layers so that a user that wouldn't otherwise have read/write privileges on a table can perform some sort of controlled update. I've written a function to serve as a type of counter to update a table called users. This function takes one (relevant) parameter: userID. This then updates the counter with that user's id. However, I am getting a permissions error because the users who run the function don't have write access to the counter table. My question is, can I somehow give permissions to the function, but not to the user to protect the counter table from being modified in any ways I don't want? Thanks, -Ben __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Functions as a Security Layer
Benjamin Stookey [EMAIL PROTECTED] writes: My question is, can I somehow give permissions to the function, but not to the user to protect the counter table from being modified in any ways I don't want? Label the function SECURITY DEFINER. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Oracle DB Worm Code Published
On 1/7/06, Magnus Hagander [EMAIL PROTECTED] wrote: A recent article about an Oracle worm: http://www.eweek.com/article2/0,1895,1880648,00.asp got me wondering. Could a worm like this infect a PostgreSQL installation? It seems to depend on default usernames and passwords - and lazy DBAs, IMO. Isn't it true that PostgreSQL doesn't have any default user/password? That's true. however, PostgreSQL ships by default with access mode set to trust, which means you don't *need* a password. And I bet you'll find the user being either postgres or pgsql in 99+% of all installations. We do, however, ship with network access disabled by default. Which means a worm can't get to it, until you enable that. But if you enable network access, and don't change it from trust to something else (such as md5), then you're wide open to this kind of entry. I don't think it's quite that easy. The default installs from SUSE and other RPM I have done are set to ident sameuser for local connections. Even if you turn on the -i flag, you can't get in remotely since there is no pg_hba.conf record for the rest of the world by default. You would have to add a record to pg_hba.conf. PostgreSQL is remarkably secure out of the box compared to Brand X. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Functions as a Security Layer
--- Benjamin Stookey [EMAIL PROTECTED] wrote: Functions, with some databases, are used as security layers so that a user that wouldn't otherwise have read/write privileges on a table can perform some sort of controlled update. I've written a function to serve as a type of counter to update a table called users. This function takes one (relevant) parameter: userID. This then updates the counter with that user's id. However, I am getting a permissions error because the users who run the function don't have write access to the counter table. My question is, can I somehow give permissions to the function, but not to the user to protect the counter table from being modified in any ways I don't want? Thanks, -Ben http://www.postgresql.org/docs/8.1/static/sql-createfunction.html Check out the difference between security invoker and security definer. If the creating user has the necessary access to the underlying objects you'll get the behavior you desire. Shelby Cain __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Functions as a Security Layer
Thanks so much. That did the trick! --- Tom Lane [EMAIL PROTECTED] wrote: Benjamin Stookey [EMAIL PROTECTED] writes: My question is, can I somehow give permissions to the function, but not to the user to protect the counter table from being modified in any ways I don't want? Label the function SECURITY DEFINER. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] userdefined types
Hello,
So I have been reading over the web and it seems that one must
define two methods before declaring a type. But I seem to have done it
(CREATE TYPE) without creating any functions and it did not give me
an error. I tried to use
INSERT TABLENAME SET user-defined-column = ROW('val1' ,'va2' ...);
and it works. The only problem is when I have ROW( , ,
'values','morevalues', ,'evenmorevalues');
it does not like the commas one after the other (empty value) how
do I solve that or does this have something to do with those two
methods (in and out) that I overlooked.
any insight would be much appreciated.
-assad
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[GENERAL] CRITICAL RELEASE: Minor Releases to Fix DoS Vulnerability
PostgreSQL patch versions 8.1.2, 8.0.6, 7.4.11 and 7.3.13 are available today. The fixes in the 8.1 and 8.0 branches are critical, especially for Windows users, and users of these branches are urged to update at their earliest opportunity. One critical fix repairs a denial-of-service vulnerability: on Windows only, the postmaster will exit if too many connection requests arrive simultaneously. This does not affect existing database connections, but will prevent new connections from being established until the postmaster is manually restarted. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2006-0105 to this issue. Another critical fix repairs an error in ReadBuffer that can cause data loss due to overwriting recently-added pages. This applies to the 8.1 and 8.0 branches on all platforms. Other fixes included are: -- Character string locale comparison bug. This may require a REINDEX on text column indexes in some locales, such as Hungarian. -- Prevent accidental changes of locale by plperl -- Two fixes for Japanese encodings -- Two fixes for COPY CSV -- Fixes for functions returning RECORD -- Fixes to autovacuum, dblink and pgcrypto Further details appear in the release notes in the documentation for the new versions, which is distributed with the source, and will be available within a few days on PostgreSQL.org. Versions 7.4.11 and 7.3.13 contain a subset of the fixes above appropriate to those versions. Currently, source packages are available for all these versions, and Windows installer packages are available for 8.1.2 and 8.0.6. Binary packages for other platforms will soon be available from the PostgreSQL Downloads[1] page and other sources. Marc G. Fournier PostgreSQL Core Member [1] - http://www.postgresql.org/download ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] userdefined types
Assad Jarrahian [EMAIL PROTECTED] writes: it does not like the commas one after the other (empty value) how do I solve that or does this have something to do with those two methods (in and out) that I overlooked. any insight would be much appreciated. You have not given us nearly enough information. It does not like is not adequate: show the *exact* error message. (Even if the details mean nothing to you, they might mean something to other people.) Given the context, I suspect there's something wrong with your C code and you'll have to show us the code to get any useful help. But I am just speculating on the basis of no evidence whatsoever ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Fedora + Yum + 8.1
I am running Fedora core 4 with nightly yum update. Presently it is not picking up version 8.1 as an upgrade. 1) If I wait will 8.1 get added to the yummy list or 2) If I add 8.1 via the RPMs will future releases be maintained by yum or do future upgrades have to continue to be done manually via RPM's thanks Richard ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] userdefined types
C code (I am confused, are you talking about c-functions and types,
cause I don't have any!)
all I have is listed below (with the last query not working)
So getting back to user-defined types, is it REALLY necessary to have
the in-out functions (just to note, I am using jdbc with the db)
Thanks!
-assad
CREATE TYPE address AS
(bldgname varchar,
bldgzone varchar,
bldgfloor varchar,
bldgroom varchar,
street varchar,
crossing1 varchar,
crossing2 varchar,
city varchar,
state varchar,
zip varchar,
district varchar,
county varchar,
country varchar,
countrycode varchar,
phonenumber varchar,
ext varchar,
url varchar);
CREATE TABLE userprofiles
(
username varchar(32) NOT NULL,
address address,
CONSTRAINT table_profiles PRIMARY KEY (username)
)
UPDATE userprofiles SET address = ROW(''
,'','','','','','','','','','','','','','','','') where
username='mooreg3';
Query returned successfully: 1 rows affected, 156 ms execution time.
UPDATE userprofiles SET address = ROW(
,'','','',,'',,'','','','','','','','','','') where
username='mooreg3';
ERROR: syntax error at or near , at character 41
On 1/9/06, Tom Lane [EMAIL PROTECTED] wrote:
Assad Jarrahian [EMAIL PROTECTED] writes:
it does not like the commas one after the other (empty value) how
do I solve that or does this have something to do with those two
methods (in and out) that I overlooked.
any insight would be much appreciated.
You have not given us nearly enough information. It does not like
is not adequate: show the *exact* error message. (Even if the details
mean nothing to you, they might mean something to other people.)
Given the context, I suspect there's something wrong with your C code
and you'll have to show us the code to get any useful help. But I am
just speculating on the basis of no evidence whatsoever ...
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
