Friday, August 15, 2008

[GENERAL] Windows Installation Problem

I'm not sure if I've violated some rule or the installation is just not
working the way I'm thinking it should work.

This is a Windows XP Professional Service Pack 2 install. Yes, I know
it sucks but until I get my app rewritten in Qt it will have to do and
even after that point I will still need this to work.

First I install 8.3.1 using this command line:
MSI (c) (F0:1C) [22:53:29:468]: Command Line: INTERNALLAUNCH=1
DOSERVICE=1 DOINITDB=1 SERVICEDOMAIN=CLAUDIAS-IGOR
SERVICEACCOUNT=pg$horseshow SERVICEPASSWORD=**********
CREATESERVICEUSER=1 SERVICENAME=pg$HORSESHOWTIME_8.3
SUPERUSER=pg$SuperUser SUPERPASSWORD=********** PERMITREMOTE=1
ADDLOCAL=server,psql,pgadmin
CURRENTDIRECTORY=C:\DOCUME~1\STEFAN~1\LOCALS~1\Temp\is-PSU3E.tmp
CLIENTUILEVEL=1 CLIENTPROCESSID=3824

The install works great and my service is named pg$HORSESHOWTIME_8.3,
the super user is pg$SuperUser and the superpassword is functional
allowing me to login via pgAdmin3.

Next I do (after a reboot because the service name, service user, super
user, and super password are not known until after the reboot) an
install of version 8.3.3 using the following command line:

MSI (c) (D8:9C) [23:03:06:843]: Command Line: REINSTALLMODE=vamus
REINSTALL=ALL
CURRENTDIRECTORY=C:\DOCUME~1\STEFAN~1\LOCALS~1\Temp\is-NDO44.tmp
CLIENTUILEVEL=1 CLIENTPROCESSID=3544

The second install blows out with the message that Service 'PostgreSQL
Database Server 8.3' (pgsql-8.3) could not be installed. Verify that
you have sufficient privileges to install system services.

Clearly it's trying to install the version upgrade using the default
service name rather than the service name I've specified and this same
error seems to perpetuate itself through all the possible install
parameters that are not default parameters.

Is there a piece I've missed or is this incorrect installation behavior?

Thank you for any light that you can shed on my problem.
---
Stefan Berglund

--
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] Incorrect results with NOT IN

Wow, very good to know. That was driving me crazy.

--
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] [Q] DNS(bind) ER model

Andrew Sullivan wrote:
> On Thu, Aug 14, 2008 at 04:20:14PM -0700, Roderick A. Anderson wrote:
>> Anyone aware of an ER model for holding name server records?
>
> What about a datatype? I have reason to believe that a company I used
> to work for implemented such a thing. There was some talk of
> releasing it, but I think there was some combination of insufficient
> demand, worries about competitive advantage, and concern about long
> term support.

Thanks A. I did a quick look and a custom TYPE may be useful.
>
> Because of my involvement in that project, I can't make direct
> recommendations about this topic. But supposing one was to go to
> various DNS-related lists, it seems to me it wouldn't be that hard to
> get information about the wire datatypes such that you'd have enough
> information to implement them in Postgres (assuming you know something
> about Postgres datatypes).

More research is on the schedule this week-end.

> One hint: remember the "unknown" RRTYPE. If you have questions about
> RRTYPEs, I'm happy to answer.

Thanks again. This is a pretty specialized application (at this time)
so the RRTYPEs used are limited. I am trying to make the model and Pg
implementation as generic as possible in case it gets released into the
wild later.

Thanks for the offer on the RRTYPEs. Zone files /can/ get pretty hairy
plus the company I'm doing this for gets some strange requests from
their customers -- not always correct or logical. :-(


Rod
--


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Regression failing on build -> ERROR: could not access file "$libdir/plpgsql": No such file or directory

I'm getting this failure on compilation. Could someone point me in the direction of a fix?

Thanks,
reid

System: AIX 5.3
$ uname -a
AIX aix53-dev-1 3 5 000B357F4C00

Configuration params:
./configure --prefix=/usr/local/pgsql833 --without-readline --disable-shared

The Error:
...SNIP...
/usr/bin/gmake -C test/regress all
gmake[2]: Entering directory `/home/rthompso/postgresql-8.3.3/src/test/regress'
/usr/bin/gmake -C ../../../src/port all
gmake[3]: Entering directory `/home/rthompso/postgresql-8.3.3/src/port'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/home/rthompso/postgresql-8.3.3/src/port'
gmake[2]: stat:regress.so: There are too many levels of symbolic links to translate a path name.
rm -f regress.so
ln -s regress.so
gmake[2]: stat:regress.so: There are too many levels of symbolic links to translate a path name.
/usr/bin/gmake -C ../../../contrib/spi refint.so autoinc.so
gmake[3]: Entering directory `/home/rthompso/postgresql-8.3.3/contrib/spi'
gmake[3]: `refint.so' is up to date.
gmake[3]: `autoinc.so' is up to date.
gmake[3]: Leaving directory `/home/rthompso/postgresql-8.3.3/contrib/spi'
rm -rf ./testtablespace
mkdir ./testtablespace
gmake[2]: Leaving directory `/home/rthompso/postgresql-8.3.3/src/test/regress'
gmake[1]: Leaving directory `/home/rthompso/postgresql-8.3.3/src'
/usr/bin/gmake -C config all
gmake[1]: Entering directory `/home/rthompso/postgresql-8.3.3/config'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/home/rthompso/postgresql-8.3.3/config'
All of PostgreSQL successfully made. Ready to install.
/usr/bin/gmake -C src/test check
gmake[1]: Entering directory `/home/rthompso/postgresql-8.3.3/src/test'
/usr/bin/gmake -C regress check
gmake[2]: Entering directory `/home/rthompso/postgresql-8.3.3/src/test/regress'
/usr/bin/gmake -C ../../../src/port all
gmake[3]: Entering directory `/home/rthompso/postgresql-8.3.3/src/port'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/home/rthompso/postgresql-8.3.3/src/port'
gmake[2]: stat:regress.so: There are too many levels of symbolic links to translate a path name.
rm -f regress.so
ln -s regress.so
gmake[2]: stat:regress.so: There are too many levels of symbolic links to translate a path name.
/usr/bin/gmake -C ../../../contrib/spi refint.so autoinc.so
gmake[3]: Entering directory `/home/rthompso/postgresql-8.3.3/contrib/spi'
gmake[3]: `refint.so' is up to date.
gmake[3]: `autoinc.so' is up to date.
gmake[3]: Leaving directory `/home/rthompso/postgresql-8.3.3/contrib/spi'
rm -rf ./testtablespace
mkdir ./testtablespace
./pg_regress --temp-install=./tmp_check --top-builddir=../../.. --srcdir=/home/rthompso/postgresql-8.3.3/src/test/regress --temp-port=55432 --schedule=./parallel_schedule --multibyte=SQL_ASCII --load-language=plpgsql
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 55432 with pid 618520
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== installing plpgsql ==============
ERROR: could not access file "$libdir/plpgsql": No such file or directory
command failed: "/home/rthompso/postgresql-8.3.3/src/test/regress/./tmp_check/install//usr/local/pgsql833/bin/psql" -X -c "CREATE LANGUAGE \"plpgsql\"" "regression"
server stopped
gmake[2]: *** [check] Error 2
gmake[2]: Leaving directory `/home/rthompso/postgresql-8.3.3/src/test/regress'
gmake[1]: *** [check] Error 2
gmake[1]: Leaving directory `/home/rthompso/postgresql-8.3.3/src/test'
gmake: *** [check] Error 2
make: 1254-004 The error code from the last command is 2.


Stop.


the lib is getting built, but appears that it is not getting installed as part of the regression test
$ pwd
/home/rthompso/postgresql-8.3.3

[rthompso@ ]/home/rthompso/postgresql-8.3.3
$ find . -name \*plpgsql\*
./doc/src/sgml/plpgsql.sgml
./src/pl/plpgsql
./src/pl/plpgsql/src/plpgsql.h
./src/pl/plpgsql/src/libplpgsql.a
./src/test/regress/expected/plpgsql.out
./src/test/regress/sql/plpgsql.sql
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-overview.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-structure.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-declarations.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-expressions.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-statements.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-control-structures.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-cursors.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-errors-and-messages.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-trigger.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-implementation.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-development-tips.html
./src/test/regress/tmp_check/install/usr/local/pgsql833/doc/html/plpgsql-porting.html

$ pwd
/home/rthompso/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql833

[rthompso@ ]/home/rthompso/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql833
$ find . -name \*plpgsql\*
./doc/html/plpgsql.html
./doc/html/plpgsql-overview.html
./doc/html/plpgsql-structure.html
./doc/html/plpgsql-declarations.html
./doc/html/plpgsql-expressions.html
./doc/html/plpgsql-statements.html
./doc/html/plpgsql-control-structures.html
./doc/html/plpgsql-cursors.html
./doc/html/plpgsql-errors-and-messages.html
./doc/html/plpgsql-trigger.html
./doc/html/plpgsql-implementation.html
./doc/html/plpgsql-development-tips.html
./doc/html/plpgsql-porting.html


--
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] Confronting the maximum column limitation

> The
> real problem lies with the columns (biological samples) in that it is
> rarely the case that we'll have multiple matrices with overlap in columns

Should each configuration have its own table, while inheriting from a common
base table?

--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Parsing of pg_hba.conf and authentication inconsistencies

Magnus Hagander wrote:
> Magnus Hagander wrote:
>
> [about the ability to use different maps for ident auth, gss and krb
> auth for example]
>
> >>>> It wouldn't be very easy/clean to do that w/o breaking the existing
> >>>> structure of pg_ident though, which makes me feel like using seperate
> >>>> files is probably the way to go.
>
> Actually, I may have to take that back. We already have support for
> multiple maps in the ident file, I'm not really sure anymore of the case
> where this wouldn't be enough :-)
>
> That said, I still think we want to parse pg_hba in the postmaster,
> because it allows us to not load known broken files, and show errors
> when you actually change the file etc. ;-)
>
> I did code up a POC patch for it, and it's not particularly hard to do.
> Mostly it's just moving the codepath from the backend to the postmaster.
> I'll clean it up a but and post it, just so ppl can see what it looks
> like...

To address Magnus' specific question, right now we store the pg_hba.conf
tokens as strings in the postmaster. I am fine with storing them in a
more native format and throwing errors for values that don't convert.
What would concern me is calling lots of 3rd party libraries from the
postmaster to validate items.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

Andreas Pflug <pgadmin@pse-consulting.de> writes:
> I wonder if you need these self defined aggregates at all, most or all
> of them are in 8.3 already.

They aren't "self defined" in 6.5 either. I think what is happening
is that he's trying to force a 7.x pg_dump to dump from the 6.5 server
(with -i no doubt), and it's just tremendously confused about what's
what and what it should dump.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Reporting the bind-parameter on an error

"Fujii Masao" <masao.fujii@gmail.com> writes:
> The bind-parameter is useful information for debugging. So, I made
> the small patch which reports the bind-parameter together with
> the SQL statement on an error.

You can't invoke user-defined I/O functions in an already-failed
transaction. For that matter, you shouldn't really even try to do the
catalog lookups involved in identifying them.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] So what about XSLT?

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>
>> An open task in replacing contrib/xml2 is the XSLT support, which the current
>> core implementation lacks altogether. I am known to often be in favor of a
>> lean core, so I have so far been hesitant to push this further, but we should
>> eventually come up with an implementation for the users' sake.
>>
>
>
>> So where should XSLT functionality live:
>>
>
> That question is unanswerable except in the context of a specific
> proposal for the amount of functionality and code involved. To take
> it to extremes: if you are talking about adding 100 lines, no one will
> object to putting it in core; if you are talking about adding 100000
> lines, some of us will object. I suppose you are thinking of something
> in between, but what?
>
>

well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just
import that to core and drop the rest of the module as redundant.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

alexander lunyov <lan@zato.ru> writes:
> I want to try new pg_dump to connect to old server, but i can't - old
> postgres doesn't listening to network socket.

It won't work anyway: modern versions of pg_dump are only designed to
work with servers back to 7.0. I see from the rest of the thread that
you tried to bludgeon it into submission, but I'd very strongly
recommend that you abandon that approach and use 6.5's pg_dump.

A further suggestion is that you use -d or even -D option on the dump.
I think there have been some corner-case changes in COPY data format
since 6.5 days; which might or might not bite you, but why take the
chance ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] So what about XSLT?

Peter Eisentraut <peter_e@gmx.net> writes:
> An open task in replacing contrib/xml2 is the XSLT support, which the current
> core implementation lacks altogether. I am known to often be in favor of a
> lean core, so I have so far been hesitant to push this further, but we should
> eventually come up with an implementation for the users' sake.

> So where should XSLT functionality live:

That question is unanswerable except in the context of a specific
proposal for the amount of functionality and code involved. To take
it to extremes: if you are talking about adding 100 lines, no one will
object to putting it in core; if you are talking about adding 100000
lines, some of us will object. I suppose you are thinking of something
in between, but what?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

Peter Eisentraut <peter_e@gmx.net> writes:
> Random googling shows me that Oracle appears to use a syntax like
> name => value
> This is actually a feature that I would like to see implemented soonish, so if
> anyone has input on the possible syntax consequences, please comment.

We've been over this territory before. The problem with "name => value"
is that it requires reserving a perfectly good user-defined operator name.
"value AS name", on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] varchar/name casts

Peter Eisentraut <peter_e@gmx.net> writes:
> Note that varchar mostly "borrows" the cast functions from the text type. The
> exception is that there is a separate set of SQL-level functions for casting
> between name and varchar and vice versa. But these are actually matched to
> the same C-level functions as the casts between text and name (name_text()
> and text_name()).

> Does anyone recall a reason for this special case or is it just another dark
> area in the casting maze?

I think the idea was to support the functional casting notation, viz
"varchar(name_col)". However it seems we've broken that already for
most of the other cases; and in any case it never worked very nicely
for varchar because "varchar" is a reserved word, so you have to
quote :-(

As a historical note, in 7.3 (the first release with a pg_cast catalog)
your query gives just

castsource | casttarget | castfunc | castcontext
-------------------+-------------------+-------------------------+-------------
name | character varying | "varchar"(name) | i
text | character varying | - | i
character | character varying | - | i
character varying | name | name(character varying) | i
character varying | text | - | i
character varying | character | - | i
(6 rows)

So it seems the cross-category casts for varchar got accreted on later,
rather than it being a case of things having disappeared.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] [Q] DNS(bind) ER model

On Fri, Aug 15, 2008 at 10:26:54AM +0100, David Goodenough wrote:
> Have you looked at mydns? It is a database driven DNS server - and it
> works just fine with Postgresql.

Given that the references section of its documentation doesn't include
a number of important RFCs, are you quite sure it's really a complete
DNS server? (Note that I haven't tested it, so I'm asking in genuine
ignorance. But the lack of a reference to RFC 2671, which defines
EDNS0, sure doesn't give me warm fuzzies. If you're deploying a name
server today and it doesn't support EDNS0, it's possible you're going
to find that some users can't resolve your names in the near future.)

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] New postgres installation

It been suggested that I download the binary and just go from there.
All the documentation I've read says that for Unix installations
should compile source. Would using the binary allow me to do the
customization my site requires. I want to put the database in it's
original location so that faculty won't have to change they're
instructions to students.

Carol

PS Again, My OS is Solaris 10.

On Aug 14, 2008, at 5:21 PM, Reed Loefgren wrote:

> Carol Walter wrote:
>> I'm running Solaris 10. I'm not sure whether I'd compile source
>> or use package manager. I haven't done enough research to know
>> which one is right for us. I will be migrating my old data into
>> the new version. I don't have any client apps that need testing -
>> yet. In fact, I don't have any client applications. I'm in an
>> academic environment. The databases I have on this server are
>> largely student creations. There are two faculty research
>> projects that are using this but one of them is closed down for
>> now, and they other is one that I'm rewriting from ColdFusion to
>> PHP, and it hasn't really started yet. That's part of my reason
>> for wanting to do this now. We are between the last summer
>> session and the start of the fall semester. This upgrade will
>> effect very few people at this time. I just really want to put
>> this back where the earlier one was, if I can. The faculty have
>> syllabi that have paths and links in them that will confuse the
>> students if things aren't where they expect.
>>
>> Carol
>>
>> On Aug 14, 2008, at 3:34 PM, Steve Crawford wrote:
>>
>>> Carol Walter wrote:
>>>> Hello,
>>>>
>>>> I want to do a new installation of postgres. I have version
>>>> 8.2.3 and I want to go to 8.3.3. The postgres documentation
>>>> says that the default location for the installation is /usr/
>>>> local/pgsql. My installation has obviously been customized
>>>> because I have no such path on my system. The documentation
>>>> also says you can customize the location by including prefix = */
>>>> PREFIX/* in the ./configuration file. Is there a way I can tell
>>>> what this customization was? There are several directories that
>>>> contain many of the same files. I have several installations of
>>>> postgres running on different servers. If this is anything like
>>>> everything else I've seen there, quite possibly, is a different
>>>> customization for each server.
>>>> Thank you very much,
>>>>
>>>> Carol Walter
>>>>
>>>>
>>> What OS?
>>>
>>> How do you plan to install (source?, package-manager?)
>>>
>>> Do you need to save data from old installation?
>>>
>>> Do you have any client applications that need testing (or is this
>>> to test them)? There are a few changes that could bite you
>>> (changes to automatic casting and changed cluster syntax to name
>>> a couple).
>>>
>>> Cheers,
>>> Steve
>>>
>>
>>
> Carol,
>
> I have never run Solaris, but you can probably find a pre-compiled
> package of 8.3.3, and instructions on installing, over at
> www.blastwave.com (.org?) They support opensolaris but might be
> what you need anyway. That would cover the Solaris part, for the
> postgresql part you'll need to look to the mailing lists or on usenet.
>
> Good luck,
>
> r


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

[GENERAL] Killing active users

Hi:

 

I have a system where I have 2 DBs.  The first is available to the users for general interaction.  The second gets reloaded with new data once per night and is then “renamed” to the active one if/when the reload went successfully, preserving the old DB as a standby.  Here’s a snapshot of that process.

 

alter database maindb rename to temp;

alter database standby rename to maindb

alter database temp rename to standby

 

The problem is that sometimes the rename fails because there are active users on the available DB... DBD::Pg::db do failed: ERROR:  database "maindb" is being accessed by other users . Because the reload takes place in the wee hours, I feel it’s OK to kill any existing user connections in order to prevent this if I have to. 

 

Q: Is there a way to kill all active users on a DB without having to reboot the DB?

Q: Or is my problem moot in that there is a way to leave those connections alone and attached to the now renamed DB?

 

Thanks in Advance for any help

-dave  

Re: [SQL] Check a column value not in Array.

>> select *
>> from test
>> where test.col not in ARRAY['val1', 'val2'];
>>
>
> select * from test where test.col <> ALL ( ARRAY['val1', 'val2'] );
>
> see http://www.postgresql.org/docs/current/static/functions-comparisons.html
>
> be careful with NULLs in this type of comparisons.

Thanks a lot for all your inputs!

For efficiency, I guess :

(1) "... where test.col <> all ARRAY['val1', 'val2']"
and
(2) "... where test.col not in ('var1', 'var2')"

provide the same query efficiency right?

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [HACKERS] proposal sql: labeled function params

Hello

2008/8/15 Peter Eisentraut <peter_e@gmx.net>:
> Am Friday, 15. August 2008 schrieb Tom Lane:
>> Hannu Krosing <hannu@2ndQuadrant.com> writes:
>> > How is this supposed to interact with argument names ?
>>
>> Yeah, the real problem with this proposal is that it conscripts a syntax
>> that we'll probably want to use in the future for argument-name-based
>> parameter matching. The proposed behavior is not nearly as useful as
>> that would be.
>
> I am not at all convinced about the proposed feature, but is that really a
> syntax we would use for function calls with named parameters?
>
> Random googling shows me that Oracle appears to use a syntax like
>
> name => value
>

I vote this syntax too. So this second feature - named params X labels
for params. Labels for params is related to my work on variadic
functions. Named params needs default param's values - and some more
of changes in parser. Somebody have to solve conflict between params
and expression.

Pavel


> This is actually a feature that I would like to see implemented soonish, so if
> anyone has input on the possible syntax consequences, please comment.
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] So what about XSLT?

On Fri, Aug 15, 2008 at 04:11:11PM +0300, Peter Eisentraut wrote:
> An open task in replacing contrib/xml2 is the XSLT support, which
> the current core implementation lacks altogether. I am known to
> often be in favor of a lean core, so I have so far been hesitant to
> push this further, but we should eventually come up with an
> implementation for the users' sake.
>
> So where should XSLT functionality live:
>
> - core

+1. I've heard rumors of a PL/XSLT. Any substance to them?

> - contrib
> - pgfoundry
>
> There is also a related but minor question where other interesting
> XML functionality should live, such as pretty-printing and
> canonicalization. These would be relatively straightward
> passthroughs to functionality provided by libxml already.
>
> Comments?

Is there some way to do a more generic (de)serialization of which one
target could be XML? CSV could be one, JSON another, and at the
moment, it appears we're taking each of these as a totally separate
project.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] table name length restriction

Am Friday, 15. August 2008 schrieb Thomas Finneid:
> First question is, what is the rationale behind having a limit on the
> table name?

Is is an implementation detail. Fixed-length name fields are more efficient
to process. And when you have fixed-length fields you need to choose some
reasonable limit to avoid wasting too much space.

> Secondly Any ideas on how to solve this problem? Is the name length
> limit configurable?

Yes, edit NAMEDATALEN in src/include/pg_config_manual.h and rebuild.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] table name length restriction

Hi

I (well, a colleague of mine) have a problem where table names are
longer than the 70 char limit. The names must be human readable, i.e. no
synthetic name mapping etc. The table creation and the created name are
executed automatically, so an algorithm to create a fancy short name is
just more pain than its worth.

First question is, what is the rationale behind having a limit on the
table name?

Secondly Any ideas on how to solve this problem? Is the name length
limit configurable?

regards

thomas

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[HACKERS] So what about XSLT?

An open task in replacing contrib/xml2 is the XSLT support, which the current
core implementation lacks altogether. I am known to often be in favor of a
lean core, so I have so far been hesitant to push this further, but we should
eventually come up with an implementation for the users' sake.

So where should XSLT functionality live:

- core
- contrib
- pgfoundry

There is also a related but minor question where other interesting XML
functionality should live, such as pretty-printing and canonicalization.
These would be relatively straightward passthroughs to functionality provided
by libxml already.

Comments?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

Am Friday, 15. August 2008 schrieb Tom Lane:
> Hannu Krosing <hannu@2ndQuadrant.com> writes:
> > How is this supposed to interact with argument names ?
>
> Yeah, the real problem with this proposal is that it conscripts a syntax
> that we'll probably want to use in the future for argument-name-based
> parameter matching. The proposed behavior is not nearly as useful as
> that would be.

I am not at all convinced about the proposed feature, but is that really a
syntax we would use for function calls with named parameters?

Random googling shows me that Oracle appears to use a syntax like

name => value

This is actually a feature that I would like to see implemented soonish, so if
anyone has input on the possible syntax consequences, please comment.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] varchar/name casts

With this query you can view all casts involving varchar:

SELECT castsource::regtype, casttarget::regtype, castfunc::regprocedure,
castcontext FROM pg_cast WHERE 'varchar'::regtype IN (castsource, casttarget)
ORDER BY 1, 2;

Note that varchar mostly "borrows" the cast functions from the text type. The
exception is that there is a separate set of SQL-level functions for casting
between name and varchar and vice versa. But these are actually matched to
the same C-level functions as the casts between text and name (name_text()
and text_name()).

Does anyone recall a reason for this special case or is it just another dark
area in the casting maze? If the latter, I would like to remove the extra
functions and redefine the casts between varchar and name to use the
SQL-level casting functions for the text type.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

2008/8/15 Peter Eisentraut <peter_e@gmx.net>:
> Am Thursday, 14. August 2008 schrieb Pavel Stehule:
>> I propose enhance current syntax that allows to specify label for any
>> function parameter:
>>
>> fcename(expr [as label], ...)
>> fcename(colname, ...)
>>
>> I would to allow same behave of custom functions like xmlforest function:
>> postgres=# select xmlforest(a) from foo;
>> xmlforest
>> -----------
>> <a>10</a>
>> (1 row)
>
> Do you have a use case for this outside of XML?
>

JSON and similar (custom) protocols

Pavel

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] XML / XSL rendering in PostgreSQL server?

Am Friday, 15. August 2008 schrieb Peter Sampson:
> I've searched the mailing lists,site, docs and Google -- to no avail. Also,
> I see that xslt_process (from xml2) will be deprecated going forward. We're
> building an app that will be used for a long time into the future, and I'd
> like to keep it future-compatible.

There is no "future-proof" XSL(T) support in PostgreSQL yet. We need to work
out how we want to do that.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

Am Thursday, 14. August 2008 schrieb Pavel Stehule:
> I propose enhance current syntax that allows to specify label for any
> function parameter:
>
> fcename(expr [as label], ...)
> fcename(colname, ...)
>
> I would to allow  same behave of custom functions like xmlforest function:
> postgres=# select xmlforest(a) from foo;
>  xmlforest
> -----------
>  <a>10</a>
> (1 row)

Do you have a use case for this outside of XML?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] XML / XSL rendering in PostgreSQL server?

Tino, thanks for your reply

I would like to use one of the XML rendering functions like table_to_xml_and_xmlschema OR table_to_xml and render the output via XSL, preferably in one query.

"What do you think would be the benefit of doing that?"

My main reason would be to embed all of the application logic in the postgres server. This way, we can build out the app more efficiently by not relying on middleware. It seems like there would be fewer cycles committed to the whole application if it was all done in the DB, but I could be wrong.

Yes, I am using pl/pgSQL for all of the internals. I could formulate and output the data this way, but if Postgres has methods for using XSL to do this, why not use it instead of re-inventing it (and we can keep the public-view logic separate from the business logic in the server)?

Thanks.

Peter


On Fri, Aug 15, 2008 at 1:46 AM, Tino Wildenhain <tino@wildenhain.de> wrote:
Hi,


Peter Sampson wrote:
Hi,

I would like to use one of the XML rendering functions like table_to_xml_and_xmlschema OR table_to_xml and render the output via XSL, preferably in one query.

What do you think would be the benefit of doing that?


I've searched the mailing lists,site, docs and Google -- to no avail. Also, I see that xslt_process (from xml2) will be deprecated going forward. We're building an app that will be used for a long time into the future, and I'd like to keep it future-compatible.

I've also searched online for sql / xml docs or tutorials, but haven't found any that directly addresses using xsl in queries itself.

You could try with one of the pl/*u languages.

Regards
Tino

Re: [HACKERS] XML / XSL rendering in PostgreSQL server?

Hi,

Peter Sampson wrote:
> Hi,
>
> I would like to use one of the XML rendering functions like
> table_to_xml_and_xmlschema OR table_to_xml and render the output via
> XSL, preferably in one query.

What do you think would be the benefit of doing that?

> I've searched the mailing lists,site, docs and Google -- to no avail.
> Also, I see that xslt_process (from xml2) will be deprecated going
> forward. We're building an app that will be used for a long time into
> the future, and I'd like to keep it future-compatible.
>
> I've also searched online for sql / xml docs or tutorials, but haven't
> found any that directly addresses using xsl in queries itself.

You could try with one of the pl/*u languages.

Regards
Tino

Re: [BUGS] BUG #4357: SERIAL pseudotype and related SEQUENCE object

Am Friday, 15. August 2008 schrieb Grigory Zinin:
> We can create SERIAL field. But INTEGER type will be really set. It's well
> known that INTEGER field doesn't match values more than 4 bytes. But
> related SEQUENCE object has a 8 byte value.
> It looks strange for me that 4 bytes of these 8 byte value will never be
> used.
> Is it bug or feature?

Well, it is that way by design, because most people will want the faster int4
type for their key fields. If you want a bigger type, you have of course
bigserial available.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] xmlAgg not found..

Am Friday, 15. August 2008 schrieb Tariq Aziz:
> I have installed PostGRESql 8.3 and try in to retrieve data in xml
> format for which I need to use function "xmlAgg". but that's not
> supported in the instance I have configured. Kindly guide me If there is
> some service pack or patch required to get this function working for me.

Since you haven't actually shown what you are trying to do and what results
you are getting, it is pretty much impossible to help you.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

Guillaume Smet wrote:
> On Fri, Aug 15, 2008 at 11:42 AM, alexander lunyov <lan@zato.ru> wrote:
>> i didn't find anything like postgresql.conf on old server. Right now i'm
>> tried to start 6.5.3 on windows (downloaded binary from ftp archive on
>> postgresql.org, installed last cygwin) with the data dir from old server,
>> but there's errors:
>
> Add the -i option to your startup command line. You should then be
> able to connect using the network.

Thanks a lot! It did a trick, so now i can connect to it. I followed
your advice and installed 7.3 client and tried to dump and get this error:

JAIL@incubator@root # pg_dump -U ira -h 192.168.0.3 itt_user
pg_dump: [archiver (db)] connection to database "itt_user" failed:
ERROR: MultiByte strings (MB) must be enabled to use this function

I searched for meaning of this error, and found solution here:

http://archives.postgresql.org/pgsql-general/2000-09/msg00489.php

"Recompile your 7.0.2 without --enable-multibyte option."

but in 7.3 configure no such option.

--
alexander lunyov

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: plan invalidation vs stored procedures

Index: src/backend/commands/functioncmds.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/commands/functioncmds.c,v
retrieving revision 1.98
diff -c -r1.98 functioncmds.c
*** src/backend/commands/functioncmds.c 18 Jul 2008 03:32:52 -0000 1.98
--- src/backend/commands/functioncmds.c 15 Aug 2008 11:12:51 -0000
***************
*** 59,64 ****
--- 59,65 ----
#include "utils/rel.h"
#include "utils/syscache.h"
#include "utils/tqual.h"
+ #include "utils/inval.h"


static void AlterFunctionOwner_internal(Relation rel, HeapTuple tup,
***************
*** 680,685 ****
--- 681,687 ----
HeapTuple languageTuple;
Form_pg_language languageStruct;
List *as_clause;
+ Oid funcOid;

/* Convert list of names to a name and namespace */
namespaceId = QualifiedNameGetCreationNamespace(stmt->funcname,
***************
*** 817,823 ****
* And now that we have all the parameters, and know we're permitted to do
* so, go ahead and create the function.
*/
! ProcedureCreate(funcname,
namespaceId,
stmt->replace,
returnsSet,
--- 819,825 ----
* And now that we have all the parameters, and know we're permitted to do
* so, go ahead and create the function.
*/
! funcOid = ProcedureCreate(funcname,
namespaceId,
stmt->replace,
returnsSet,
***************
*** 837,842 ****
--- 839,848 ----
PointerGetDatum(proconfig),
procost,
prorows);
+
+ /* Send invalidation on REPLACE */
+ if (stmt->replace)
+ CacheInvalidateProcedure(funcOid);
}


***************
*** 906,911 ****
--- 912,920 ----
object.objectSubId = 0;

performDeletion(&object, stmt->behavior);
+
+ /* Notify that cached plans should be replanned */
+ CacheInvalidateProcedure(funcOid);
}

/*
***************
*** 1029,1034 ****
--- 1038,1046 ----

heap_close(rel, NoLock);
heap_freetuple(tup);
+
+ /* Need plan invalidation after this */
+ CacheInvalidateProcedure(procOid);
}

/*
***************
*** 1294,1299 ****
--- 1306,1314 ----

heap_close(rel, NoLock);
heap_freetuple(tup);
+
+ /* Invalidate plans after this */
+ CacheInvalidateProcedure(funcOid);
}

/*
Index: src/backend/commands/prepare.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/commands/prepare.c,v
retrieving revision 1.89
diff -c -r1.89 prepare.c
*** src/backend/commands/prepare.c 21 Jul 2008 15:26:55 -0000 1.89
--- src/backend/commands/prepare.c 15 Aug 2008 11:12:52 -0000
***************
*** 188,196 ****
/* Shouldn't have a non-fully-planned plancache entry */
if (!entry->plansource->fully_planned)
elog(ERROR, "EXECUTE does not support unplanned prepared statements");
- /* Shouldn't get any non-fixed-result cached plan, either */
- if (!entry->plansource->fixed_result)
- elog(ERROR, "EXECUTE does not support variable-result cached plans");

/* Evaluate parameters, if any */
if (entry->plansource->num_params > 0)
--- 188,193 ----
***************
*** 462,468 ****
cursor_options,
stmt_list,
true,
! true);

/* Now we can add entry to hash table */
entry = (PreparedStatement *) hash_search(prepared_queries,
--- 459,465 ----
cursor_options,
stmt_list,
true,
! false);

/* Now we can add entry to hash table */
entry = (PreparedStatement *) hash_search(prepared_queries,
***************
*** 523,533 ****
TupleDesc
FetchPreparedStatementResultDesc(PreparedStatement *stmt)
{
! /*
! * Since we don't allow prepared statements' result tupdescs to change,
! * there's no need for a revalidate call here.
! */
! Assert(stmt->plansource->fixed_result);
if (stmt->plansource->resultDesc)
return CreateTupleDescCopy(stmt->plansource->resultDesc);
else
--- 520,528 ----
TupleDesc
FetchPreparedStatementResultDesc(PreparedStatement *stmt)
{
! /* Revalidate the plan to allow changes in tupdescs. */
! RevalidateCachedPlan(stmt->plansource, false);
!
if (stmt->plansource->resultDesc)
return CreateTupleDescCopy(stmt->plansource->resultDesc);
else
***************
*** 649,657 ****
/* Shouldn't have a non-fully-planned plancache entry */
if (!entry->plansource->fully_planned)
elog(ERROR, "EXPLAIN EXECUTE does not support unplanned prepared statements");
- /* Shouldn't get any non-fixed-result cached plan, either */
- if (!entry->plansource->fixed_result)
- elog(ERROR, "EXPLAIN EXECUTE does not support variable-result cached plans");

/* Replan if needed, and acquire a transient refcount */
cplan = RevalidateCachedPlan(entry->plansource, true);
--- 644,649 ----
Index: src/backend/nodes/copyfuncs.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/nodes/copyfuncs.c,v
retrieving revision 1.399
diff -c -r1.399 copyfuncs.c
*** src/backend/nodes/copyfuncs.c 7 Aug 2008 19:35:02 -0000 1.399
--- src/backend/nodes/copyfuncs.c 15 Aug 2008 11:12:53 -0000
***************
*** 84,89 ****
--- 84,90 ----
COPY_NODE_FIELD(returningLists);
COPY_NODE_FIELD(rowMarks);
COPY_NODE_FIELD(relationOids);
+ COPY_NODE_FIELD(functionOids);
COPY_SCALAR_FIELD(nParamExec);

return newnode;
***************
*** 1866,1871 ****
--- 1867,1873 ----
COPY_NODE_FIELD(limitCount);
COPY_NODE_FIELD(rowMarks);
COPY_NODE_FIELD(setOperations);
+ COPY_NODE_FIELD(functionOids);

return newnode;
}
Index: src/backend/optimizer/plan/planner.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v
retrieving revision 1.240
diff -c -r1.240 planner.c
*** src/backend/optimizer/plan/planner.c 7 Aug 2008 01:11:50 -0000 1.240
--- src/backend/optimizer/plan/planner.c 15 Aug 2008 11:12:54 -0000
***************
*** 215,220 ****
--- 215,221 ----
result->rowMarks = parse->rowMarks;
result->relationOids = glob->relationOids;
result->nParamExec = list_length(glob->paramlist);
+ result->functionOids = parse->functionOids;

return result;
}
Index: src/backend/parser/analyze.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/parser/analyze.c,v
retrieving revision 1.376
diff -c -r1.376 analyze.c
*** src/backend/parser/analyze.c 7 Aug 2008 01:11:51 -0000 1.376
--- src/backend/parser/analyze.c 15 Aug 2008 11:12:55 -0000
***************
*** 227,232 ****
--- 227,235 ----
result->querySource = QSRC_ORIGINAL;
result->canSetTag = true;

+ /* Add the function oid list to Query */
+ result->functionOids = pstate->p_functionOids;
+
return result;
}

Index: src/backend/parser/parse_func.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/parser/parse_func.c,v
retrieving revision 1.204
diff -c -r1.204 parse_func.c
*** src/backend/parser/parse_func.c 30 Jul 2008 17:05:04 -0000 1.204
--- src/backend/parser/parse_func.c 15 Aug 2008 11:12:55 -0000
***************
*** 323,328 ****
--- 323,332 ----
parser_errposition(pstate, location)));
}

+ /* add the function Oid to ParseState - this is later copied to Query */
+ if (!list_member_oid(pstate->p_functionOids, funcid))
+ pstate->p_functionOids = lappend_oid(pstate->p_functionOids, funcid);
+
return retval;
}

Index: src/backend/tcop/postgres.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.555
diff -c -r1.555 postgres.c
*** src/backend/tcop/postgres.c 1 Aug 2008 13:16:09 -0000 1.555
--- src/backend/tcop/postgres.c 15 Aug 2008 11:12:57 -0000
***************
*** 2177,2184 ****
errmsg("unnamed prepared statement does not exist")));
}

! /* Prepared statements shouldn't have changeable result descs */
! Assert(psrc->fixed_result);

/*
* If we are in aborted transaction state, we can't run
--- 2177,2184 ----
errmsg("unnamed prepared statement does not exist")));
}

! /* Revalidate the plan to allow tupdesc changes */
! RevalidateCachedPlan(psrc, true);

/*
* If we are in aborted transaction state, we can't run
Index: src/backend/utils/cache/inval.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/cache/inval.c,v
retrieving revision 1.86
diff -c -r1.86 inval.c
*** src/backend/utils/cache/inval.c 19 Jun 2008 21:32:56 -0000 1.86
--- src/backend/utils/cache/inval.c 15 Aug 2008 11:12:57 -0000
***************
*** 115,121 ****
typedef struct InvalidationListHeader
{
InvalidationChunk *cclist; /* list of chunks holding catcache msgs */
! InvalidationChunk *rclist; /* list of chunks holding relcache/smgr msgs */
} InvalidationListHeader;

/*----------------
--- 115,121 ----
typedef struct InvalidationListHeader
{
InvalidationChunk *cclist; /* list of chunks holding catcache msgs */
! InvalidationChunk *rclist; /* list of chunks holding relcache/smgr/proc msgs */
} InvalidationListHeader;

/*----------------
***************
*** 177,182 ****
--- 177,183 ----
#define TWOPHASE_INFO_FILE_AFTER 2 /* relcache file inval */

static void PersistInvalidationMessage(SharedInvalidationMessage *msg);
+ static void CacheRegisterCallback(int cacheid, CacheCallbackFunction func, Datum arg);


/* ----------------------------------------------------------------
***************
*** 363,368 ****
--- 364,393 ----
}

/*
+ * Add a proc inval entry
+ */
+ static void
+ AddProcInvalidationMessage(InvalidationListHeader *hdr,
+ Oid dbId, Oid procId)
+ {
+ SharedInvalidationMessage msg;
+
+ /* Don't add a duplicate item */
+ /* We assume dbId need not be checked because it will never change */
+
+ ProcessMessageList(hdr->rclist,
+ if (msg->pm.id == SHAREDINVALPROC_ID &&
+ msg->pm.procId == procId)
+ return);
+
+ /* OK, add the item */
+ msg.pm.id = SHAREDINVALPROC_ID;
+ msg.pm.dbId = dbId;
+ msg.pm.procId = procId;
+ AddInvalidationMessage(&hdr->rclist, &msg);
+ }
+
+ /*
* Append one list of invalidation messages to another, resetting
* the source list to empty.
*/
***************
*** 465,470 ****
--- 490,512 ----
}

/*
+ * RegisterProcInvalidation
+ *
+ * As above, but register a procedure invalidation event.
+ */
+ static void
+ RegisterProcInvalidation(Oid dbId, Oid procId)
+ {
+ AddProcInvalidationMessage(&transInvalInfo->CurrentCmdInvalidMsgs,
+ dbId, procId);
+
+ /*
+ * As above, just in case there is not an associated catalog change.
+ */
+ (void) GetCurrentCommandId(true);
+ }
+
+ /*
* LocalExecuteInvalidationMessage
*
* Process a single invalidation message (which could be of any type).
***************
*** 516,521 ****
--- 558,577 ----
*/
smgrclosenode(msg->sm.rnode);
}
+ else if (msg->id == SHAREDINVALPROC_ID)
+ {
+ if (msg->rc.dbId == MyDatabaseId)
+ {
+ /* for now we just need to handle callback functions */
+ for (i = 0; i < cache_callback_count; i++)
+ {
+ struct CACHECALLBACK *ccitem = cache_callback_list + i;
+
+ if (ccitem->id == SHAREDINVALPROC_ID)
+ (*ccitem->function) (ccitem->arg, msg->rc.relId);
+ }
+ }
+ }
else
elog(FATAL, "unrecognized SI message id: %d", msg->id);
}
***************
*** 1175,1191 ****
}

/*
! * CacheRegisterSyscacheCallback
* Register the specified function to be called for all future
* invalidation events in the specified cache.
*
- * NOTE: currently, the OID argument to the callback routine is not
- * provided for syscache callbacks; the routine doesn't really get any
- * useful info as to exactly what changed. It should treat every call
- * as a "cache flush" request.
*/
! void
! CacheRegisterSyscacheCallback(int cacheid,
CacheCallbackFunction func,
Datum arg)
{
--- 1231,1254 ----
}

/*
! * CacheInvalidateProcedure
! * Register invalidation of the specified stored procedure.
! *
! */
! void
! CacheInvalidateProcedure(Oid procId)
! {
! RegisterProcInvalidation(MyDatabaseId, procId);
! }
!
! /*
! * CacheRegisterCallback
* Register the specified function to be called for all future
* invalidation events in the specified cache.
*
*/
! static void
! CacheRegisterCallback(int cacheid,
CacheCallbackFunction func,
Datum arg)
{
***************
*** 1199,1204 ****
--- 1262,1286 ----
++cache_callback_count;
}

+
+ /*
+ * CacheRegisterSyscacheCallback
+ * Register the specified function to be called for all future
+ * invalidation events in the specified cache.
+ *
+ * NOTE: currently, the OID argument to the callback routine is not
+ * provided for syscache callbacks; the routine doesn't really get any
+ * useful info as to exactly what changed. It should treat every call
+ * as a "cache flush" request.
+ */
+ void
+ CacheRegisterSyscacheCallback(int cacheid,
+ CacheCallbackFunction func,
+ Datum arg)
+ {
+ CacheRegisterCallback(cacheid, func, arg);
+ }
+
/*
* CacheRegisterRelcacheCallback
* Register the specified function to be called for all future
***************
*** 1212,1223 ****
CacheRegisterRelcacheCallback(CacheCallbackFunction func,
Datum arg)
{
! if (cache_callback_count >= MAX_CACHE_CALLBACKS)
! elog(FATAL, "out of cache_callback_list slots");
!
! cache_callback_list[cache_callback_count].id = SHAREDINVALRELCACHE_ID;
! cache_callback_list[cache_callback_count].function = func;
! cache_callback_list[cache_callback_count].arg = arg;

! ++cache_callback_count;
}
--- 1294,1311 ----
CacheRegisterRelcacheCallback(CacheCallbackFunction func,
Datum arg)
{
! CacheRegisterCallback(SHAREDINVALRELCACHE_ID, func, arg);
! }

! /*
! * CacheRegisterProcCallback
! * Register the specified function to be called for all future
! * proccache invalidation events. The OID of the procedure being
! * invalidated will be passed to the function.
! */
! void
! CacheRegisterProcCallback(CacheCallbackFunction func, Datum arg)
! {
! CacheRegisterCallback(SHAREDINVALPROC_ID, func, arg);
}
+
Index: src/backend/utils/cache/plancache.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/cache/plancache.c,v
retrieving revision 1.19
diff -c -r1.19 plancache.c
*** src/backend/utils/cache/plancache.c 18 Jul 2008 20:26:06 -0000 1.19
--- src/backend/utils/cache/plancache.c 15 Aug 2008 11:12:58 -0000
***************
*** 82,89 ****
--- 82,91 ----
static bool rowmark_member(List *rowMarks, int rt_index);
static bool plan_list_is_transient(List *stmt_list);
static void PlanCacheCallback(Datum arg, Oid relid);
+ static void PlanCacheProcCallback(Datum arg, Oid procId);
static void InvalRelid(Oid relid, LOCKMODE lockmode,
InvalRelidContext *context);
+ static void ScanForInvalidations(Oid objId, bool is_function_oid);


/*
***************
*** 95,100 ****
--- 97,103 ----
InitPlanCache(void)
{
CacheRegisterRelcacheCallback(PlanCacheCallback, (Datum) 0);
+ CacheRegisterProcCallback(PlanCacheProcCallback, (Datum) 0);
}

/*
***************
*** 863,876 ****
}

/*
! * PlanCacheCallback
* Relcache inval callback function
*
! * Invalidate all plans mentioning the given rel, or all plans mentioning
! * any rel at all if relid == InvalidOid.
*/
static void
! PlanCacheCallback(Datum arg, Oid relid)
{
ListCell *lc1;
ListCell *lc2;
--- 866,879 ----
}

/*
! * ScanForInvalidations
* Relcache inval callback function
*
! * Invalidate all plans mentioning the given object, or all plans mentioning
! * any object at all if objId == InvalidOid.
*/
static void
! ScanForInvalidations(Oid objId, bool is_function_oid)
{
ListCell *lc1;
ListCell *lc2;
***************
*** 888,899 ****
foreach(lc2, plan->stmt_list)
{
PlannedStmt *plannedstmt = (PlannedStmt *) lfirst(lc2);

Assert(!IsA(plannedstmt, Query));
if (!IsA(plannedstmt, PlannedStmt))
continue; /* Ignore utility statements */
! if ((relid == InvalidOid) ? plannedstmt->relationOids != NIL :
! list_member_oid(plannedstmt->relationOids, relid))
{
/* Invalidate the plan! */
plan->dead = true;
--- 891,911 ----
foreach(lc2, plan->stmt_list)
{
PlannedStmt *plannedstmt = (PlannedStmt *) lfirst(lc2);
+ bool invalidate = false;

Assert(!IsA(plannedstmt, Query));
if (!IsA(plannedstmt, PlannedStmt))
continue; /* Ignore utility statements */
!
! if (objId == InvalidOid)
! /* invalidate everything */
! invalidate = true;
! else if (is_function_oid)
! invalidate = list_member_oid(plannedstmt->functionOids, objId);
! else
! invalidate = list_member_oid(plannedstmt->relationOids, objId);
!
! if (invalidate)
{
/* Invalidate the plan! */
plan->dead = true;
***************
*** 910,916 ****
*/
InvalRelidContext context;

! context.inval_relid = relid;
context.plan = plan;

foreach(lc2, plan->stmt_list)
--- 922,928 ----
*/
InvalRelidContext context;

! context.inval_relid = objId;
context.plan = plan;

foreach(lc2, plan->stmt_list)
***************
*** 918,930 ****
Query *query = (Query *) lfirst(lc2);

Assert(IsA(query, Query));
! ScanQueryForRelids(query, InvalRelid, (void *) &context);
}
}
}
}

/*
* ResetPlanCache: drop all cached plans.
*/
void
--- 930,977 ----
Query *query = (Query *) lfirst(lc2);

Assert(IsA(query, Query));
!
! if (is_function_oid)
! {
! /* Functions are easy - we already have the list of OIDs in Query */
! if (objId == InvalidOid ||
! list_member_oid(query->functionOids, objId))
! {
! plan->dead = true;
! break;
! }
! }
! else
! {
! /* No precomputed relation OID list in Query - need to scan */
! ScanQueryForRelids(query, InvalRelid, (void *) &context);
! }
}
}
}
}

/*
+ * PlanCacheCallback
+ * Relcache inval callback function
+ */
+ static void
+ PlanCacheCallback(Datum arg, Oid relid)
+ {
+ ScanForInvalidations(relid, false);
+ }
+
+ /*
+ * PlanCacheProcCallback
+ * Stored procedure invalidation callback function
+ */
+ static void
+ PlanCacheProcCallback(Datum arg, Oid procId)
+ {
+ ScanForInvalidations(procId, true);
+ }
+
+ /*
* ResetPlanCache: drop all cached plans.
*/
void
Index: src/include/nodes/parsenodes.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/nodes/parsenodes.h,v
retrieving revision 1.371
diff -c -r1.371 parsenodes.h
*** src/include/nodes/parsenodes.h 7 Aug 2008 01:11:51 -0000 1.371
--- src/include/nodes/parsenodes.h 15 Aug 2008 11:12:59 -0000
***************
*** 132,137 ****
--- 132,139 ----

Node *setOperations; /* set-operation tree if this is top level of
* a UNION/INTERSECT/EXCEPT query */
+
+ List *functionOids; /* OIDs of functions the query references */
} Query;


Index: src/include/nodes/plannodes.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/nodes/plannodes.h,v
retrieving revision 1.102
diff -c -r1.102 plannodes.h
*** src/include/nodes/plannodes.h 7 Aug 2008 19:35:02 -0000 1.102
--- src/include/nodes/plannodes.h 15 Aug 2008 11:12:59 -0000
***************
*** 72,77 ****
--- 72,79 ----

List *relationOids; /* OIDs of relations the plan depends on */

+ List *functionOids; /* OIDs of functions the plan depends on */
+
int nParamExec; /* number of PARAM_EXEC Params used */
} PlannedStmt;

Index: src/include/parser/parse_node.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/parser/parse_node.h,v
retrieving revision 1.54
diff -c -r1.54 parse_node.h
*** src/include/parser/parse_node.h 19 Jun 2008 00:46:06 -0000 1.54
--- src/include/parser/parse_node.h 15 Aug 2008 11:12:59 -0000
***************
*** 80,85 ****
--- 80,86 ----
bool p_is_update;
Relation p_target_relation;
RangeTblEntry *p_target_rangetblentry;
+ List *p_functionOids;
} ParseState;

extern ParseState *make_parsestate(ParseState *parentParseState);
Index: src/include/storage/sinval.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/storage/sinval.h,v
retrieving revision 1.48
diff -c -r1.48 sinval.h
*** src/include/storage/sinval.h 19 Jun 2008 21:32:56 -0000 1.48
--- src/include/storage/sinval.h 15 Aug 2008 11:12:59 -0000
***************
*** 74,85 ****
--- 74,95 ----
RelFileNode rnode; /* physical file ID */
} SharedInvalSmgrMsg;

+ #define SHAREDINVALPROC_ID (-3)
+
+ typedef struct
+ {
+ int16 id; /* type field --- must be first */
+ Oid dbId; /* database ID */
+ Oid procId; /* procedure ID */
+ } SharedInvalProcMsg;
+
typedef union
{
int16 id; /* type field --- must be first */
SharedInvalCatcacheMsg cc;
SharedInvalRelcacheMsg rc;
SharedInvalSmgrMsg sm;
+ SharedInvalProcMsg pm;
} SharedInvalidationMessage;


Index: src/include/utils/inval.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/utils/inval.h,v
retrieving revision 1.43
diff -c -r1.43 inval.h
*** src/include/utils/inval.h 19 Jun 2008 00:46:06 -0000 1.43
--- src/include/utils/inval.h 15 Aug 2008 11:12:59 -0000
***************
*** 49,54 ****
--- 49,56 ----

extern void CacheInvalidateRelcacheByRelid(Oid relid);

+ extern void CacheInvalidateProcedure(Oid procId);
+
extern void CacheRegisterSyscacheCallback(int cacheid,
CacheCallbackFunction func,
Datum arg);
***************
*** 56,61 ****
--- 58,66 ----
extern void CacheRegisterRelcacheCallback(CacheCallbackFunction func,
Datum arg);

+ extern void CacheRegisterProcCallback(CacheCallbackFunction func,
+ Datum arg);
+
extern void inval_twophase_postcommit(TransactionId xid, uint16 info,
void *recdata, uint32 len);

Index: src/test/regress/expected/plancache.out
===================================================================
RCS file: /projects/cvsroot/pgsql/src/test/regress/expected/plancache.out,v
retrieving revision 1.7
diff -c -r1.7 plancache.out
*** src/test/regress/expected/plancache.out 8 Jun 2008 22:41:04 -0000 1.7
--- src/test/regress/expected/plancache.out 15 Aug 2008 11:13:01 -0000
***************
*** 53,61 ****
-- since clients probably aren't expecting that to change on the fly
ALTER TABLE pcachetest ADD COLUMN q3 bigint;
EXECUTE prepstmt;
! ERROR: cached plan must not change result type
EXECUTE prepstmt2(123);
! ERROR: cached plan must not change result type
-- but we're nice guys and will let you undo your mistake
ALTER TABLE pcachetest DROP COLUMN q3;
EXECUTE prepstmt;
--- 53,74 ----
-- since clients probably aren't expecting that to change on the fly
ALTER TABLE pcachetest ADD COLUMN q3 bigint;
EXECUTE prepstmt;
! q1 | q2 | q3
! ------------------+-------------------+----
! 4567890123456789 | -4567890123456789 |
! 4567890123456789 | 123 |
! 123 | 456 |
! 123 | 4567890123456789 |
! 4567890123456789 | 4567890123456789 |
! (5 rows)
!
EXECUTE prepstmt2(123);
! q1 | q2 | q3
! -----+------------------+----
! 123 | 456 |
! 123 | 4567890123456789 |
! (2 rows)
!
-- but we're nice guys and will let you undo your mistake
ALTER TABLE pcachetest DROP COLUMN q3;
EXECUTE prepstmt;
Tom Lane wrote:
> Martin Pihlak <martin.pihlak@gmail.com> writes:
>> Changing statement result type is also currently prohibited in
>> StorePreparedStatement. There maybe good reasons for this,
>
> How about "the SQL spec says so"?
>
> Admittedly, it's a bit of a jump from views to prepared statements,
> but the spec is perfectly clear that altering a table doesn't alter
> any views dependent on it: SQL99 11.11 <add column definition> saith

As you said it is a bit of a jump ... For one thing view definitions are
persistent whereas statements are bound to be replanned sooner or later -
reconnects etc. Disallowing replanning after invalidation just postpones
it and meanwhile the cached plans are left unusable ("cached plan must not
change result"). IMHO the problem should be left for the application to handle.
Because this is where it will end up anyway.

Attached is a patch that implements plan invalidation on function DROP,
REPLACE and ALTER. Function oids used by the query are collected in analyze phase
and stored in PlannedStmt. Only plans that reference the altered function are
invalidated. The patch also enables replanning on result set change.

regards,
Martin

[COMMITTERS] stackbuilder - wizard: It's kinda useful if we actually install the

Log Message:
-----------
It's kinda useful if we actually install the binary as well as the message catalogs :-p

Modified Files:
--------------
wizard:
CMakeLists.txt (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/CMakeLists.txt.diff?r1=1.7&r2=1.8)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

alexander lunyov wrote:
> Andreas Pflug wrote:
>>>>> I want to try new pg_dump to connect to old server, but i can't - old
>>>>> postgres doesn't listening to network socket. Why postgres 6.5.3 not
>>>>> binding to network socket? It started with this line:
>>
>> Maybe you should just dump schema and data separately with your old
>> pg_dump tool, then rework the schema for 8.3 manually.
>
> I can do this, but i don't know how to rework it.
I wonder if you need these self defined aggregates at all, most or all
of them are in 8.3 already.

Regards,
Andreas


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Reporting the bind-parameter on an error

Hi,

Currently, the SQL statement that causes an error condition is reported
in the server log. On the other hand, the bind-parameter is not reported
as following.

> FATAL: terminating connection due to administrator command
> STATEMENT: UPDATE tbl SET name = $1 WHERE id = $2
> LOG: shutting down

The bind-parameter is useful information for debugging. So, I made
the small patch which reports the bind-parameter together with
the SQL statement on an error.

> FATAL: terminating connection due to administrator command
> STATEMENT: UPDATE tbl SET name = $1 WHERE id = $2
> DETAIL: parameters: $1 = 'hoge', $2 = '1'
> LOG: shutting down

Any comments welcome!

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

[GENERAL] UTF8 in commandprompt (CMD) on XP fails. Tips?

Hi group,

I am trying to set up a testenvironment on my developmachine (XP Prof
SP3), using PHP as a scriptinglanguage to access Postgres (8.3).

I am working on a multilanguagal database, so I picked UTF8 as encoding
for this database.

Right now I am able to:
1) Send information (Including UTF8) from a html form to PHP.
2) Pick up the info in PHP, and insert it into Postgres
3) Get the info out of Postgres, and display it right as HTML in a
browser. (Using HTML strict and encoding UTF-8 of course).

So far so good.

My problem started with using psql.
psql complained to me it couldn't display all characters right when I
started my session.
So I changed the encoding to UTF8, using:
\encoding UTF8

Now I can query from commandline, but many UTF8 characters are displayed
wrong.
(NOT if I use a webbrowser with UTF8, but only commandline)

I read something on the net about using a different font and change my
codepage.
I did this (without succes):
1) Changed the font of the dosshell to Lucida Console
2) Gave the command chcp 65001

Now, if I give a simple SQL command, it responds with:
Not Enough Memory.

I am not sure if this is a Postgres problem or Microsoft (probably the
latter)

Anyway, Is it possible to have psql working with UTF8 in a windows
commandprompt?

TIA!

Regards,
Erwin Moller

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

On Fri, Aug 15, 2008 at 11:42 AM, alexander lunyov <lan@zato.ru> wrote:
> i didn't find anything like postgresql.conf on old server. Right now i'm
> tried to start 6.5.3 on windows (downloaded binary from ftp archive on
> postgresql.org, installed last cygwin) with the data dir from old server,
> but there's errors:

Add the -i option to your startup command line. You should then be
able to connect using the network.

That said, you should also be able to connect using the unix domain
socket using -h /path/to/domain option.

--
Guillaume

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [ADMIN] DB Dump Size

On Fri, Aug 15, 2008 at 11:09:02AM +1000, steve@outtalimits.com.au wrote:
> Nice, that has cleared it up.
>
> I am on 8.1 also.
>
> On my test box, a standard dump took 6m 26sec & a -Fc dump took 11min 2sec.
> That's not a great difference, but the size difference is quite noticeable.

You might use --compress=6 or even --compress=1 to lower the impact of
compression and try again. On the other hand, 11 minutes is not a big
deal for dumping a whole DB...

Tino.

--
"What we nourish flourishes." - "Was wir nähren erblüht."

www.craniosacralzentrum.de
www.forteego.de

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

Andreas Pflug wrote:
>>>> I want to try new pg_dump to connect to old server, but i can't - old
>>>> postgres doesn't listening to network socket. Why postgres 6.5.3 not
>>>> binding to network socket? It started with this line:
>
> Maybe you should just dump schema and data separately with your old
> pg_dump tool, then rework the schema for 8.3 manually.

I can do this, but i don't know how to rework it.

psql:dump:389: WARNING: aggregate attribute "sfunc2" not recognized
psql:dump:389: WARNING: aggregate attribute "stype2" not recognized
psql:dump:389: WARNING: aggregate attribute "initcond2" not recognized
psql:dump:389: ERROR: function int84div(bigint) does not exist
psql:dump:390: ERROR: function int4div(integer) does not exist
psql:dump:391: ERROR: function int2div(smallint) does not exist
psql:dump:392: ERROR: function float4div(real) does not exist
psql:dump:393: ERROR: function float8div(double precision) does not exist
psql:dump:394: ERROR: function cash_div_flt8(money) does not exist
psql:dump:395: ERROR: type "timespan" does not exist
psql:dump:396: ERROR: function numeric_div(numeric) does not exist
psql:dump:410: ERROR: function int4larger(abstime, abstime) does not exist
psql:dump:422: ERROR: function int4smaller(abstime, abstime) does not exist
psql:dump:413: ERROR: type "datetime" does not exist
psql:dump:429: ERROR: aggregate stype must be specified

If i understand it right, much of this errors are about AGGREGATEs (they
are a part of schema):

CREATE AGGREGATE avg ( BASETYPE = int8, SFUNC1 = int8pl, STYPE1 = int8,
INITCOND1 = '', SFUNC2 = int4inc, STYPE2 = int4, INITCOND
2 = '0', FINALFUNC = int84div );

CREATE AGGREGATE avg ( BASETYPE = int4, SFUNC1 = int4pl, STYPE1 = int4,
INITCOND1 = '', SFUNC2 = int4inc, STYPE2 = int4, INITCOND
2 = '0', FINALFUNC = int4div );

CREATE AGGREGATE avg ( BASETYPE = int2, SFUNC1 = int2pl, STYPE1 = int2,
INITCOND1 = '', SFUNC2 = int2inc, STYPE2 = int2, INITCOND
2 = '0', FINALFUNC = int2div );

CREATE AGGREGATE avg ( BASETYPE = float4, SFUNC1 = float4pl, STYPE1 =
float4, INITCOND1 = '', SFUNC2 = float4inc, STYPE2 = float4
, INITCOND2 = '0.0', FINALFUNC = float4div );

CREATE AGGREGATE avg ( BASETYPE = float8, SFUNC1 = float8pl, STYPE1 =
float8, INITCOND1 = '', SFUNC2 = float8inc, STYPE2 = float8
, INITCOND2 = '0.0', FINALFUNC = float8div );

CREATE AGGREGATE avg ( BASETYPE = money, SFUNC1 = cash_pl, STYPE1 =
money, INITCOND1 = '', SFUNC2 = float8inc, STYPE2 = float8, I
NITCOND2 = '0.0', FINALFUNC = cash_div_flt8 );

CREATE AGGREGATE avg ( BASETYPE = timespan, SFUNC1 = timespan_pl,
STYPE1 = timespan, INITCOND1 = '', SFUNC2 = float8inc, STYPE2 =
float8, INITCOND2 = '0.0', FINALFUNC = timespan_div );

CREATE AGGREGATE avg ( BASETYPE = numeric, SFUNC1 = numeric_add, STYPE1
= numeric, INITCOND1 = '', SFUNC2 = numeric_inc, STYPE2 =
numeric, INITCOND2 = '0', FINALFUNC = numeric_div );

So, i have to replace these float4div to some new equivalent? And where
can i find those equivalents for all these functions and special words,
that "doesn't exists"?

--
alexander lunyov

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[GENERAL] Delete across 5 Joined tables

Hi,
I am trying to delete a set of related record across the whole
database, In tests I
have managed to delete records from 2 tables using the code below.

DELETE FROM phillipsd.tablea using phillipsd.tableb WHERE tablea.one =
2;

but I need to be able to delete from up to 5 different tables, is
there a quick and
simple way of doing this? can someone post an example?

Cheers
David P

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

alexander lunyov wrote:
> Guillaume Smet wrote:
>>> I want to try new pg_dump to connect to old server, but i can't - old
>>> postgres doesn't listening to network socket. Why postgres 6.5.3 not
>>> binding to network socket? It started with this line:

Maybe you should just dump schema and data separately with your old
pg_dump tool, then rework the schema for 8.3 manually.

Regards,
Andreas


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [BUGS] BUG #4357: SERIAL pseudotype and related SEQUENCE object

Grigory Zinin пишет:
> The following bug has been logged online:
>
> Bug reference: 4357
> Logged by: Grigory Zinin
> Email address: Grigory.Zinin@com.mels.ru
> PostgreSQL version: 8.3.2
> Operating system: win32 x86
> Description: SERIAL pseudotype and related SEQUENCE object
> Details:
>
> It's possible that somebody already had found this thing, but I couldn't
> find any references to this in archives.
> We can create SERIAL field. But INTEGER type will be really set. It's well
> known that INTEGER field doesn't match values more than 4 bytes. But related
> SEQUENCE object has a 8 byte value.
> It looks strange for me that 4 bytes of these 8 byte value will never be
> used.
> Is it bug or feature?
>
>
A little mistake here.
Correct version 8.3.3 (latest)

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4357: SERIAL pseudotype and related SEQUENCE object

The following bug has been logged online:

Bug reference: 4357
Logged by: Grigory Zinin
Email address: Grigory.Zinin@com.mels.ru
PostgreSQL version: 8.3.2
Operating system: win32 x86
Description: SERIAL pseudotype and related SEQUENCE object
Details:

It's possible that somebody already had found this thing, but I couldn't
find any references to this in archives.
We can create SERIAL field. But INTEGER type will be really set. It's well
known that INTEGER field doesn't match values more than 4 bytes. But related
SEQUENCE object has a 8 byte value.
It looks strange for me that 4 bytes of these 8 byte value will never be
used.
Is it bug or feature?

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

Guillaume Smet wrote:
>> I want to try new pg_dump to connect to old server, but i can't - old
>> postgres doesn't listening to network socket. Why postgres 6.5.3 not
>> binding to network socket? It started with this line:
> Do you have something like tcpip_socket in your postgresql.conf (I
> don't know if it was in 6.5)? If so, you have to set it to true to
> make PostgreSQL listen on the network.

i didn't find anything like postgresql.conf on old server. Right now i'm
tried to start 6.5.3 on windows (downloaded binary from ftp archive on
postgresql.org, installed last cygwin) with the data dir from old
server, but there's errors:

D:\pgsql\bin>d:\pgsql\bin\postgres -p 5432 -D d:\\pgsql\\data
6 [main] postgres 2820 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
426 [main] postgres 2820 open_stackdumpfile: Dumping stack trace to
postgres.exe.stackdump
27692 [main] postgres 2820 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
28338 [main] postgres 2820 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)

dump:

Exception: STATUS_ACCESS_VIOLATION at eip=0044EBE3
eax=00000000 ebx=00506A90 ecx=00000000 edx=00000001 esi=00506AD1
edi=004E83FC
ebp=02862BBC esp=02862BA8 program=d:\pgsql\bin\postgres.exe, pid 2820,
thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
02862BBC 0044EBE3 (00000045, 02862BF8, 00000000, 00000000)
02868BF8 004E5A93 (00000001, 004E83C8, 00000000, 0286CC80)
02868C0C 004E8460 (04870150, 0286CCF8, 0044F5A4, 00000000)
0286CC80 004B3518 (00000005, 04870150, 00000005, 04870150)
0286CCB4 0044F698 (00000005, 04870150, 04870090, 60030000)
0286CDA4 610060D8 (00000000, 0286CDDC, 61005450, 0286CDDC)
61005450 61004416 (0000009C, A02404C7, E8611021, FFFFFF48)
27692 [main] postgres 2820 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
28338 [main] postgres 2820 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)

Also tried to compile 6.5.3 from source on newer freebsd - configure
doesn't do Makefiles, errors are:


creating GNUmakefile
sed: 35: conftest.s1: unescaped newline inside substitute pattern

and for all Makefiles this message, and Makefiles are empty, so i can't
compile it.

:(

> As for the upgrade path, I'll go with:
> - dump with 7.3 pg_dump, insert your dump into a 7.3 db and run
> adddepends contrib shipped with 7.3 on your db (it should fix the
> foreign key problem reported by Zdenek);
> - then dump your 7.3 db with 8.3 pg_dump and insert your dump into
> your 8.3 server.

Ok, that's understood, thanks (thank you too, Zdenek).
But how can i connect with newer pg_dump to this old server, if it's
doesn't make a socket to connect to?

--
С уважением
Александр Лунев
МП РТК

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] [Q] DNS(bind) ER model

On Friday 15 August 2008, Roderick A. Anderson wrote:
> Anyone aware of an ER model for holding name server records?
>
> Working on the zone file data and I am getting close but keep running
> into the differences between MX records (with a priority) and the others
> that can hold either a domain/sub-domain/host name or an IP address
> depending on whether is an A, TXT, PTR, etc. or a CNAME.
>
> Much of the database will be populated and changed automagically so the
> controller for the application will do the right thing but humans will
> get involved every so often. I hope I can get the database to make the
> right thing easy and the wrong thing "impossible" for them.
>
> Any suggestions?
>
>
> Rod
> --

Have you looked at mydns? It is a database driven DNS server - and it
works just fine with Postgresql.

David

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Update taking forever

The below statement is now running for 18 hours on a table with ~8 Million Rows, no triggers no fancy stuff. The database is otherwise performing very well and the server is a development server that's currently idle except for the update statement. Any suggestions why it takes so long to update a couple million rows?

update characters set last_update = null

Note: 'last_update' is a timestamp column but the column does not seem to influence the time it takes to complete the update.

--
Oliver

Re: [HACKERS] migrate data 6.5.3 -> 8.3.1

On Fri, Aug 15, 2008 at 9:54 AM, alexander lunyov <lan@zato.ru> wrote:
> Thanks for the tip.
> I want to try new pg_dump to connect to old server, but i can't - old
> postgres doesn't listening to network socket. Why postgres 6.5.3 not
> binding to network socket? It started with this line:

(Forgot the list, sorry for the double email, Alexander)

Do you have something like tcpip_socket in your postgresql.conf (I
don't know if it was in 6.5)? If so, you have to set it to true to
make PostgreSQL listen on the network.

As for the upgrade path, I'll go with:
- dump with 7.3 pg_dump, insert your dump into a 7.3 db and run
adddepends contrib shipped with 7.3 on your db (it should fix the
foreign key problem reported by Zdenek);
- then dump your 7.3 db with 8.3 pg_dump and insert your dump into
your 8.3 server.

--
Guillaume

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] XML / XSL rendering in PostgreSQL server?

Hi,

I would like to use one of the XML rendering functions like table_to_xml_and_xmlschema OR table_to_xml and render the output via XSL, preferably in one query.

I've searched the mailing lists,site, docs and Google -- to no avail. Also, I see that xslt_process (from xml2) will be deprecated going forward. We're building an app that will be used for a long time into the future, and I'd like to keep it future-compatible.

I've also searched online for sql / xml docs or tutorials, but haven't found any that directly addresses using xsl in queries itself.

First, is this even possible without  xslt_process ? If so, how?

Any ideas?

Thanks a lot!

Regards,

Peter Sampson

[COMMITTERS] pgsql: Make the temporary directory for pgstat files configurable by the

Log Message:
-----------
Make the temporary directory for pgstat files configurable by the GUC
variable stats_temp_directory, instead of requiring the admin to
mount/symlink the pg_stat_tmp directory manually.

For now the config variable is PGC_POSTMASTER. Room for further improvment
that would allow it to be changed on-the-fly.

Modified Files:
--------------
pgsql/src/backend/postmaster:
pgstat.c (r1.178 -> r1.179)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c?r1=1.178&r2=1.179)
pgsql/src/backend/utils/misc:
guc.c (r1.465 -> r1.466)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.465&r2=1.466)
postgresql.conf.sample (r1.243 -> r1.244)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/postgresql.conf.sample?r1=1.243&r2=1.244)
pgsql/src/include:
pgstat.h (r1.77 -> r1.78)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pgstat.h?r1=1.77&r2=1.78)
pgsql/doc/src/sgml:
config.sgml (r1.184 -> r1.185)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.184&r2=1.185)
monitoring.sgml (r1.61 -> r1.62)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/monitoring.sgml?r1=1.61&r2=1.62)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers