Re: [HACKERS] Little mess in RPM RH ?

2003-12-28 Thread Sander Steffann
Hi,

 Inside the RH9.0 coesist the 7.4.0-0.3 and 7.4.0-0.5 versions
 looking on other RH directory version I found that actually

 7.4.0-0.2
 7.4.0-0.3
 7.4.0-0.4
 7.4.0-0.5

 are existing.
 Inside the SRPMS directory is present only the 7.4.0-0.2
 version!

This is because when I built the RPMs for RedHat there were little
differences between the different RedHat releases that caused the builds to
fail. I had to make minor adjustments for each platform, which is why there
are so many different release versions. The contents of the RPMs is
identical, only the build instructions differ. The SRPMs for all these
versions are at http://opensource.nederland.net/PostgreSQL/.

Lamar Owen (who creates the original SRPM) knows what has to be changed for
each platform, so I am confident that we won't have this many release again
for the next release.

 I'm able to put my hand on RH 8.0, RH 9.0, RHAS 2.1 and RHAS 3.0
 and RH 7.3 systems, if you need some help let me know.

Thanks for the offer. I can't do RHEL 3.0 yet, so if you could build the
RPMs for that platform that would be great. I still have a RH 6.2 machine in
case anybody still wants that.

Thanks,
Sander.


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] new-line

2003-12-28 Thread Andrew Dunstan

AFAICS the server doesn't know (and in my opinion shouldn't care) what
platform a non-local client is running on. This appears to be purely a
client-side issue. Furthermore, on Windows, if you are writing the data
you get from Postgres to a file which you opened in non-binary mode,
Windows will do the translation for you (something we actually have to be
careful of in doing the Windows port).

cheers

andrew

ivan said:



 its must be in run time, server should has text with linux new line,
 and if clinet is windows, postgres would convert \n to \n\r
 but when clinet is also linux postgresa can do nothing about it

 :)
 any idea ?

 On Sat, 27 Dec 2003, [iso-8859-1] Jürgen Cappel wrote:

 Hi Ivan,

 maybe your're looking for something like this:

 http://rcamera.org/cgi-bin/man2html.cgi?1+unix2dos

 HTH,

 Jürgen Cappel


 ivan [EMAIL PROTECTED] schrieb am 27.12.2003, 14:19:10:
 
 
  is there same easy way to turn on translation bettwen client and
  server from linux new-line style (0x0A) to windows style (0x0A0D?)
  (something like conversions) ?
 




---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] Connecting to Postgres

2003-12-28 Thread Tony Reina
In postgresql.conf the first entry should be something like 'tcpip'.
Set it to 'true'. That's the equivalent of the postmaster -D.

HTH,
-Tony



[EMAIL PROTECTED] (Nailah Ogeer) wrote in message news:[EMAIL PROTECTED]...
 How do you connect to postgres if it is running on a different machine. I
 am looking for a telnet command in place of postmaster -D data
 
 
 
 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] Little mess in RPM RH ?

2003-12-28 Thread Gaetano Mendola
Sander Steffann wrote:

Hi,


Inside the RH9.0 coesist the 7.4.0-0.3 and 7.4.0-0.5 versions
looking on other RH directory version I found that actually
7.4.0-0.2
7.4.0-0.3
7.4.0-0.4
7.4.0-0.5
are existing.
Inside the SRPMS directory is present only the 7.4.0-0.2
version!


This is because when I built the RPMs for RedHat there were little
differences between the different RedHat releases that caused the builds to
fail. I had to make minor adjustments for each platform, which is why there
are so many different release versions. The contents of the RPMs is
identical, only the build instructions differ. The SRPMs for all these
versions are at http://opensource.nederland.net/PostgreSQL/.
Gasp! Another site popped up ! Why aren't these SRPMs in an official
Postgresql site ?

Thanks for the offer. I can't do RHEL 3.0 yet, so if you could build the
RPMs for that platform that would be great. I still have a RH 6.2 machine in
case anybody still wants that.
I'll do it tomorrow, or is may be better do it for the 7.4.1 ?

Regards
Gaetano Mendola
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [HACKERS] [GENERAL] Strange permission problem regarding pg_settings

2003-12-28 Thread Tom Lane
Joe Conway [EMAIL PROTECTED] writes:
 Why wouldn't we force checkAsUser to the rule owner in the copied RTEs, 
 similar to the rest of the rule query?

Because it would be the wrong check.  We need to check that the rule
caller has permissions on the view for whatever he originally tried
to do (ie, the type of the original query that referenced the view).
In the non-INSTEAD case, this check will be redundant with a check
applied when the original query is executed ... but in the INSTEAD case,
it isn't redundant.

 It makes sense in that the rule 
 query could possibly use the RTE (although as you pointed out it doesn't 
 in this case), and therefore the permission check should be the same, no?

No; it's possible for the amalgamated query to include references to
tables that are referenced only in the original query and nowhere in the
text of the rule.  (This is obviously possible right now, since we just
take the union of the two rtables and don't make any effort to discard
unreferenced RTEs ... but I think it could happen even if we did discard
unreferenced RTEs, because conditions from the original query get pushed
into the rule and might reference tables that the rule text doesn't
mention.)  Checking such tables for rule-owner access would be wrong;
they have to be checked for access by the rule caller.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[HACKERS] How to get oprname ??

2003-12-28 Thread Ramanujam H S Iyengar
Hello ,

I was trying to write a patch code in converting the querytree being 
generated after the pg_analyze_and_rewrite().
For that I want to know the operator name ( like =,  ,  etc ) .. but the 
Oper node stores the opno 

How to get the operator from the opno ???

Thanks for the Help in advance,

Hals

_
Murphy's Laws. They are crazy and funny. 
http://server1.msn.co.in/features/murphy/index.asp Buy the complete book 
online now!

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match


Re: [HACKERS] [GENERAL] Strange permission problem regarding pg_settings

2003-12-28 Thread Joe Conway
Tom Lane wrote:
No; it's possible for the amalgamated query to include references to
tables that are referenced only in the original query and nowhere in the
text of the rule.  (This is obviously possible right now, since we just
take the union of the two rtables and don't make any effort to discard
unreferenced RTEs ... but I think it could happen even if we did discard
unreferenced RTEs, because conditions from the original query get pushed
into the rule and might reference tables that the rule text doesn't
mention.)  Checking such tables for rule-owner access would be wrong;
they have to be checked for access by the rule caller.
OK, so the permission check performed on the original query RTEs, while 
executing the rule query is:

 1) redundant for non-INSTEAD cases
and
 2) wrong if the original query and rule query are different modes
The patch at the root of this discussion eliminates both issues, but 
leaves us with no check at all in the INSTEAD case. Is there any way to 
do the permission checks on the original query in the INSTEAD case, even 
though the query itself will never be executed?

Joe



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


[HACKERS] select from table with unique values

2003-12-28 Thread ivan


hi

how to do select from same table to get only unique values from same
column(s) ?



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] select from table with unique values

2003-12-28 Thread Christopher Kings-Lynne
how to do select from same table to get only unique values from same
column(s) ?
SELECT DISTINCT a, b FROM tab;

or even:

SELECT DISTINCT ON (a) a, b FROM tab;

Chris

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] Use of 'cp -r' in CREATE DATABASE

2003-12-28 Thread Andrew Dunstan


Tom Lane wrote:

A final point is that implementing CREATE DATABASE via cp -r is and
always has been fundamentally broken anyway, because of the lack of
interlocking against other backends changing the source database.
We have a very half-baked defense against that (erroring out if anyone
else is connected to the source DB at the start of the copy) which
I would dearly love to get rid of.  

It struck me this morning that we could strengthen that defense 
considerable with the addition of some checks after the copy on the 
mtimes of the copied files. The additional code could be quite small and 
fast.

Longer term, a robust mechanism for DB level locks would probably be 
preferable, I guess, so I'm not sure if my idea is worth doing in the 
mean time. Presumably it hasn't caused much of a problem up to now, 
since most people are not likely to monkey with their template dbs at 
the same time as trying to create dbs based on them.

cheers

andrew

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] Use of 'cp -r' in CREATE DATABASE

2003-12-28 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 Longer term, a robust mechanism for DB level locks would probably be 
 preferable, I guess, so I'm not sure if my idea is worth doing in the 
 mean time. Presumably it hasn't caused much of a problem up to now, 
 since most people are not likely to monkey with their template dbs at 
 the same time as trying to create dbs based on them.

Actually, we do get regular complaints about CREATE DATABASE failing
because template1 is busy, and that's not because the users are actually
*doing* anything to template1, it's just because template1 is the
default database-to-connect-to for a whole lot of operations like
createuser, createdb itself, psql -l, yadda yadda, and so other backends
tend to be transiently connected to template1 even though they have no
intention of doing anything to that database in particular.

A quick-and-dirty solution would be to make another template database,
so that the default-connection-target could be different from the
default-copy-source, but that would cost a fair amount of disk space
(compared to a minimal installation) and create lots of backwards
compatibility issues too.

I'd like to see a locking-type solution myself, but I'm not sure what
the semantics look like.  For things like createuser we'd need to invent
a lock type that says I'm connected to this database but I only plan to
modify global tables, or something like that.  Messy.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match