[GENERAL] subquery in FROM must have an alias

Hi all,

This has been asked before and answered as well.
http://archives.postgresql.org/pgsql-sql/2007-12/msg00002.php but I
still cant figure out why postgres throws this error message even when
I have provided the aliases. My query:

select a,b
from (billing.item JOIN (
select *
from ( billing.invoice JOIN billing.customer
on (id_customer_shipped = customer_uid and
address = 'pgh' ))
as temp2 ))
as temp;

I have two from clauses so I have provided two corresponding alias
names for those two from clauses. But, still I get the error message

ERROR: subquery in FROM must have an alias
HINT: For example, FROM (SELECT ...) [AS] foo.

Any help on this will be greatly appreciated. I am using version 8.3.3
running on ubuntu.

Thanks,
Ashutosh

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

[COMMITTERS] npgsql - Npgsql2: Quote uuid constants when used in expression.

Log Message:
-----------
Quote uuid constants when used in expression. Thanks to Yann Robin for the fix.

Modified Files:
--------------
Npgsql2/src/Npgsql/SqlGenerators:
VisitedExpression.cs (r1.9 -> r1.10)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/SqlGenerators/VisitedExpression.cs.diff?r1=1.9&r2=1.10)

--
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] Null row vs. row of nulls in plpgsql

Iirc the reason for this fuzziness came from the SQL spec definition
of IS NULL for rows. As long as you maintain that level of spec-
compliance I don't think there are any other important constraints on
pg behaviour.

greg

--sorry for the top posting but the phone makes it hard to do anything
else.

On 27 Sep 2008, at 09:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I looked a bit at the bug report here:
> http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php
>
> ISTM that the fundamental problem is that plpgsql doesn't distinguish
> properly between a null row value (eg, "null::somerowtype") and a
> row of null values (eg, "row(null,null,...)::somerowtype"). When that
> code was designed, our main SQL engine was pretty fuzzy about the
> difference too, but now there is a clear semantic distinction.
>
> For plpgsql's RECORD variables this doesn't seem hard to fix: just
> take out the code in exec_move_row() that manufactures a row of nulls
> when the input is null, and maybe make a few small adjustments
> elsewhere. For ROW variables there's a bigger problem, because those
> are represented by a list of per-field variables, which doesn't
> immediately offer any way to represent overall nullness. I think it
> could be dealt with by adding an explicit "the row as a whole is null"
> flag to struct PLpgSQL_row. I haven't tried to code it though, so I'm
> not sure if there are gotchas or unreasonably large code changes
> needed
> to make it happen.
>
> I thought for a little bit about whether we couldn't get rid of ROW
> variables entirely, or at least make them work more like RECORD
> variables
> by storing a HeapTuple instead of a list of per-field variables. But
> I soon found out that the reason to have them is to be able to
> describe
> the assignment target of SQL statements that assign to multiple scalar
> variables, eg "SELECT ... INTO x,y,z".
>
> Comments?
>
> 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

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

[GENERAL] GISVM - FOSS4G 2008 Special Edition

Dear all,

I am proud to announce the "GIS Virtual Machine" FOSS4G 2008 Special Edition, available at: http://www.gisvm.com

This full-feature GIS Workstation, based exclusively on free GIS software, now also includes "Kosmo 1.2" and the "uDIG 1.1" Sanity Check release. The one that will be used on uDIG Lab presentation at Cape Town!!!

Please feel free to download it and enjoy!!!

Regards,
--
Ricardo Pinho

PS.
These are the GISVM specs:

GISVM - FOSS4G 2008 Special Edition
Free and ready to use anywhere GIS Virtual Machine Workstation.
A FOSS4G 2008 Special Edition!

________________________________

Features
VMware info
- CPUs : 1
- RAM : 512 MB
- Networking : NAT
- Harddisk : 8 GB SCSI (expanding)
- VMware tools : Installed
- Sound card : Enabled
- USB : Enabled
OS info
- OS : Ubuntu 8.04 Desktop
- Installation : Standard
- Hostname : gisvm
- Patches : till date of creation
- IPv4 address : dhcp
- IPv6 address : dhcp
- DNS name : none
- Nameserver : dhcp
- Route : dhcp
- Root password: not set (use sudo to execute commands as root)
- User login : user
- User password: user
- Keyboard : US-intl
- Date created : 18-09-2008

GIS DESKTOP APPLICATIONS AVAILABLE
- Quantum GIS 0.11.0 Metis + GRASS
- gvSIG 1.2
- FWTools 2.0.6 (Open EV, GDAL/OGR, Proj.4, OGDI, Mapserver, Python)
- (NEW!!!) uDIG 1.1 SC 2 as presented at FOSS4G 2008
- (NEW!!!) Kosmo 1.2, an excellent Arcview clone

GIS SERVER APPLICATIONS AVAILABLE

PostgreSQL 8.3 + PostGIS 1.3.3-1 + pgAdminIII
- Database : postgis
- Login : postgres
- Password : postgres

JAVA 6 JDK + TOMCAT 6.0.18
- Port Number : 8080
- Manager login: admin
- Password : admin

GeoSERVER 1.7.0 RC1
- Login : admin
- Password : geoserver

Apache 2 + PHP 5.2.4 + Mapserver 5.1 + PHP Mapscript
- CGI-BIN : http://localhost/cgi-bin/mapserv
- WWW Root : /var/www/

General purpose applications available:
- OpenOffice2.4: Writer, Calc, Impress, Draw
- Internet : Firefox, Evolution Mail, Ekiga Softphone, Transmission Bit Torrent Client
- Graphics : F-Spot Photo Manager, GIMP Image Editor, XSane Image Scanner
- Sound & Video: Audio CD Extractor, Brasero Disc Burning, Movie Player, Rhythmbox Music Player, Sound Recorder
And thats all!

Problems and feedback: http://www.gisvm.com/forum
Keep informed on: http://www.gisvm.com/blog
Brought to you by Ricardo Pinho (http://www.gisvm.com)
Based on the ubuntu804desktop by Chrysaor (http://chrysaor.info)

______________________________

Technical Specifications
Operating System:
Ubuntu 8.04 Hardy
VMware Tools installed: Yes
Size: 1000MB
Allocated Memory (RAM): 512
Torrent Available

Applications Installed:

GIS DESKTOP APPLICATIONS
- Quantum GIS 0.11.0 Metis + GRASS
- gvSIG 1.2
- FWTools 2.0.6 (Open EV, GDAL/OGR, Proj.4, OGDI, Mapserver, Python)
- (NEW!!!) uDIG 1.1 S.C. 2
- (NEW!!!) Kosmo 1.2

GIS SERVER APPLICATIONS
- PostgreSQL 8.3 + PostGIS 1.3.3-1 + pgAdminIII
- JAVA 6 JDK + TOMCAT 6.0.18
- GeoSERVER 1.7.0 RC1
- Apache 2 + PHP 5.2.4 + Mapserver 5.1 + PHP Mapscript

GENERAL PURPOSE APPLICATIONS
- OpenOffice2.4: Writer, Calc, Impress, Draw
- Internet : Firefox, Evolution Mail, Ekiga Softphone, Transmission Bit Torrent Client
- Graphics : F-Spot Photo Manager, GIMP Image Editor, XSane Image Scanner
- Sound & Video: Audio CD Extractor, Brasero Disc Burning, Movie Player, Rhythmbox Music Player, Sound Recorder

Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses

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

Re: [PERFORM] Slow updates, poor IO

On Sat, Sep 27, 2008 at 4:33 PM, John Huttley <John@mib-infotech.co.nz> wrote:
>
> > > this is part of the trade-offs of MVCC.
>
> > was... was a part of the trade-offs.
>
> You are thinking of HOT?
> I don't think it applies in the case of full table updates??

Sure, you just need a table with plenty of empty space in it, either
from vacuumed previous deletes / inserts or with a low fill factor
like 50%.

> It's really an effect of parallel updates / writes / accesses, and is
> always an issue for a database running on a poor storage subsystem. A
> db with a two drive mirror set is always going to be at a disadvantage
> to one running on a dozen or so drives in a RAID-10
>
> Oh well, I'm forever going to be disadvantaged.

Why? A decent caching raid controller and a set of 4 to 8 SATA drives
can make a world of difference and the cost is not that high for the
gain in performance. Even going to 4 drives in a software RAID-10 can
make a lot of difference in these situations, and that can be done
with spare machines and hard drives.

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

Re: [PERFORM] Slow updates, poor IO

Scott Marlowe wrote:

On Fri, Sep 26, 2008 at 5:03 PM, John Huttley <John@mib-infotech.co.nz> wrote:   

Hi Andrew, There are two problems. The first is the that if there is a table with a index and an update is performed on a non indexed field, the index is still re indexed.     

 I assume you mean updated, not reindexed, as reindexed has a different meaning as regards postgresql.  Also, this is no longer true as of version 8.3.  If you're updating non-indexed fields a lot and you're not running 8.3 you are doing yourself a huge disservice.    

Yes sorry, I mean all indexes are updated even when the updated field is not indexed.
I'm running 8.3.3

this is part of the trade-offs of MVCC.     

 was...  was a part of the trade-offs.    

You are thinking of HOT?
I don't think it applies in the case of full table updates??

We should reasonably expect that the total amount of IO will go up, over a non-indexed table.  The second thing is that the disk IO throughput goes way down.  This is not an issue with MVCC, as such, except that it exposes the effect of a write to an indexed field.     

 It's really an effect of parallel updates / writes / accesses, and is always an issue for a database running on a poor storage subsystem.  A db with a two drive mirror set is always going to be at a disadvantage to one running on a dozen or so drives in a RAID-10    

Oh well, I'm forever going to be disadvantaged.

Re: [HACKERS] Null row vs. row of nulls in plpgsql

On Sat, 2008-09-27 at 14:56 -0400, Tom Lane wrote:
> I looked a bit at the bug report here:
> http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php
>
> ISTM that the fundamental problem is that plpgsql doesn't distinguish
> properly between a null row value (eg, "null::somerowtype") and a
> row of null values (eg, "row(null,null,...)::somerowtype"). When that
> code was designed, our main SQL engine was pretty fuzzy about the
> difference too, but now there is a clear semantic distinction.
>
> For plpgsql's RECORD variables this doesn't seem hard to fix: just
> take out the code in exec_move_row() that manufactures a row of nulls
> when the input is null, and maybe make a few small adjustments
> elsewhere. For ROW variables there's a bigger problem, because those
> are represented by a list of per-field variables, which doesn't
> immediately offer any way to represent overall nullness. I think it
> could be dealt with by adding an explicit "the row as a whole is null"
> flag to struct PLpgSQL_row. I haven't tried to code it though, so I'm
> not sure if there are gotchas or unreasonably large code changes needed
> to make it happen.
>
> I thought for a little bit about whether we couldn't get rid of ROW
> variables entirely, or at least make them work more like RECORD variables
> by storing a HeapTuple instead of a list of per-field variables. But
> I soon found out that the reason to have them is to be able to describe
> the assignment target of SQL statements that assign to multiple scalar
> variables, eg "SELECT ... INTO x,y,z".

How hard would it be to have a RECORD that has pointers to those
multiple scalar variables ?

Referring again to my favorite ordinary programming language python, you
can have a very elegant way of assigning a "record" (a tuple in
pythonese) to a set of variables and vice versa

>>> rec = 1,2,3
>>> rec
(1, 2, 3)
>>> a,b,c = rec
>>> a
1
>>> c
3
>>> c,b,a
(3, 2, 1)

In other words, tuples are more or less automatically composed and
decomposed on demand.

I have not yet looked how hard the implementation of this would be for
postgreSQL, but at least the concept should be applicable.

----------------
Hannu

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

Re: [pgeu-general] European PostgreSQL Day 2008's schedule has been published

On Sat, 27 Sep 2008, Gabriele Bartolini wrote:

> Ciao!
>
> I'm pleased to announce that the schedule for the European PGDay 2008
> conference has now been published. Over the course of the two day
> conference, there are 28 sessions planned covering a wide range of
> topics in both English and Italian.
>
> For complete details of the schedule, please see
> http://www.pgday.org/en/schedule .

Is't possible to know, who is going to present talks. I don't see
any names. Particularly, I'm interested in two GiST related talks.
Probably, I can provide some help to authors.

>
> PGDay 2008 is a free PostgreSQL conference being held in Prato,
> Tuscany, Italy on October the 17th and 18th. For more details, please
> see the website: http://www.pgday.org/ .
>
> Registration for the conference is free, however places are limited
> for safety reasons. To avoid disappointment, please register as soon as
> possible at http://register.pgday.org/ .
>
> Thanks,
> Gabriele
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

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

Re: [pgsql-advocacy] Going to XLDB

It's interesting, but I contacted with XLDB people independently a week ago.
We have astronomical DB about 6 TB size and in a 2-3 year expect
300-400 TB from our future telescope mounted on ISS.
That's why I'm interested in joining XLDB development.

Oleg
On Fri, 26 Sep 2008, Josh Berkus wrote:

> Folks,
>
> I'm attending Stanford's XLDB[1] (eXtremely Large Databases) conference as
> the PostgreSQL representative for the first time. This will be cool.
>
> Send me any huge PostgreSQL data warehouse war stories which you have.
>
> [1]http://www-conf.slac.stanford.edu/xldb08/
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

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

[HACKERS] Fwd: Null row vs. row of nulls in plpgsql

---------- Forwarded message ----------
From: Oleg Serov <serovov@gmail.com>
Date: 2008/9/27
Subject: Re: Null row vs. row of nulls in plpgsql
To: Tom Lane <tgl@sss.pgh.pa.us>

I'm newbie, but i think that adding bool flag to PLpgSQL_row isnull will handle the problem(like in PLpgSQL_var);

2008/9/27 Tom Lane <tgl@sss.pgh.pa.us>

I looked a bit at the bug report here:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php

ISTM that the fundamental problem is that plpgsql doesn't distinguish
properly between a null row value (eg, "null::somerowtype") and a
row of null values (eg, "row(null,null,...)::somerowtype").  When that
code was designed, our main SQL engine was pretty fuzzy about the
difference too, but now there is a clear semantic distinction.

For plpgsql's RECORD variables this doesn't seem hard to fix: just
take out the code in exec_move_row() that manufactures a row of nulls
when the input is null, and maybe make a few small adjustments
elsewhere.  For ROW variables there's a bigger problem, because those
are represented by a list of per-field variables, which doesn't
immediately offer any way to represent overall nullness.  I think it
could be dealt with by adding an explicit "the row as a whole is null"
flag to struct PLpgSQL_row.  I haven't tried to code it though, so I'm
not sure if there are gotchas or unreasonably large code changes needed
to make it happen.

I thought for a little bit about whether we couldn't get rid of ROW
variables entirely, or at least make them work more like RECORD variables
by storing a HeapTuple instead of a list of per-field variables.  But
I soon found out that the reason to have them is to be able to describe
the assignment target of SQL statements that assign to multiple scalar
variables, eg "SELECT ... INTO x,y,z".

Comments?

                       regards, tom lane

[HACKERS] Null row vs. row of nulls in plpgsql

I looked a bit at the bug report here:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php

ISTM that the fundamental problem is that plpgsql doesn't distinguish
properly between a null row value (eg, "null::somerowtype") and a
row of null values (eg, "row(null,null,...)::somerowtype"). When that
code was designed, our main SQL engine was pretty fuzzy about the
difference too, but now there is a clear semantic distinction.

For plpgsql's RECORD variables this doesn't seem hard to fix: just
take out the code in exec_move_row() that manufactures a row of nulls
when the input is null, and maybe make a few small adjustments
elsewhere. For ROW variables there's a bigger problem, because those
are represented by a list of per-field variables, which doesn't
immediately offer any way to represent overall nullness. I think it
could be dealt with by adding an explicit "the row as a whole is null"
flag to struct PLpgSQL_row. I haven't tried to code it though, so I'm
not sure if there are gotchas or unreasonably large code changes needed
to make it happen.

I thought for a little bit about whether we couldn't get rid of ROW
variables entirely, or at least make them work more like RECORD variables
by storing a HeapTuple instead of a list of per-field variables. But
I soon found out that the reason to have them is to be able to describe
the assignment target of SQL statements that assign to multiple scalar
variables, eg "SELECT ... INTO x,y,z".

Comments?

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] Minor bug/inconveniance with restore from backup, using PITR base backup and archived wal files

Tom Lane wrote:
> Tommy Gildseth <tommy.gildseth@usit.uio.no> writes:
>> After a bit of looking around, and with some help from the fine people
>> in #postgresql on freenode, I think I figured out what was going on.
>> The last wal archive file was 00000001000000030000009F, and after
>> finishing recovery, postgresql created the file 00000002000000030000009F
>> (ie. 00000002 instead of 00000001) in pg_xlog.
>
> It's customary for PG to "create" new XLOG segments by recycling old
> ones.
>
>> The wal-files were
>> archived read-only, and this file permission seemed to be carried over
>> to the new file created by postgresql in pg_xlog, causing the cluster to
>> fall over and die.
>
> I would say that the bug is in your restore script: it should have made
> sure that the files it copies into the xlog directory are given the
> right ownership/permissions.

Well, the restore command(script) is simply copied from the suggestion
in the manual (restore_command = 'cp /path/to/my/archived/wal/files/%f
"%p"'). In my opinion, it's not very obvious that the last wal file
needs read/write permissions set, and it's certainly not documented
anywhere on
http://www.postgresql.org/docs/current/static/continuous-archiving.html
that I can see.
There's also the matter of the inconsistency that postgresql knows to
recycle *and* chmod the file if it's originally located in pg_xlog/
folder, but not if it's originally located in the wal files archive
folder. I guess it's more of a gotcha than a bug per se.

--
Tommy Gildseth

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

[pgeu-general] European PostgreSQL Day 2008's schedule has been published

Ciao!

I'm pleased to announce that the schedule for the European PGDay 2008
conference has now been published. Over the course of the two day
conference, there are 28 sessions planned covering a wide range of
topics in both English and Italian.

For complete details of the schedule, please see
http://www.pgday.org/en/schedule .

PGDay 2008 is a free PostgreSQL conference being held in Prato,
Tuscany, Italy on October the 17th and 18th. For more details, please
see the website: http://www.pgday.org/ .

Registration for the conference is free, however places are limited
for safety reasons. To avoid disappointment, please register as soon as
possible at http://register.pgday.org/ .

Thanks,
Gabriele
--
Gabriele Bartolini - Responsabile logistica PostgreSQL Day 2008
gabriele.bartolini@pgday.org - www.pgday.org - www.postgresql.org
Associazione Culturale Italian PostgreSQL Users Group - www.itpug.org
"PostgreSQL, the world's most advanced open-source database"

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

[pgsql-jobs] Pg server hacks needed: alter catalogs to only show permitted/owned objects

Please contact me via email off-list. This phase is getting
quotes/estimates for the work, which will lead to the client's decision
as to whether to move forward.

We have a system where many users share the same database, with varying
permissions to tables. We also host multiple databases, named after the
customer for administrative purposes. We want various pg_catalog tables
modified to only show "appropriate" objects, so as to preserve the
privacy of our customers and to simplify the view to show only items to
which the user has access. While some system views do this (eg
pg_catalog.tables) many do not (eg pg_catalog.tablespace) and it's these
latter which are used by most clients.

Specifics so far, and additional suggestions are welcome along these veins:

* These changes cannot be made just to the psql client; we need them
made at the server level so they cannot be bypassed simply by switching
clients! Still, I'll use the psql \ commands for brevity.

* Superusers should see all tables and databases, the current behavior.

* \dt and \ds et al should only show items to which the user has access.

* \l should only show the existing database, not others.

* Having a postgresql.conf option to toggle these "simplifications" may
be appropriate.

These changes must be contributed back to the PgSQL project if the PgSQL
project will accept them (I believe them to be of great applicability in
a shared-hosting environment), with credits to yourself for the code and
to our client for the funding.

--
Gregor Mosheh / Greg Allensworth BS, A+, Network+, Security+, Server+
System Administrator, Lead Programmer
HostGIS development & hosting services, http://www.HostGIS.com/

"Remember that no one cares if you can back up,
only if you can restore." - AMANDA

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

[COMMITTERS] pgsql: Compare escaped chars case insensitively for ILIKE - per gripe

Log Message:
-----------
Compare escaped chars case insensitively for ILIKE - per gripe from TGL.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/backend/utils/adt:
like_match.c (r1.20.2.1 -> r1.20.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/like_match.c?r1=1.20.2.1&r2=1.20.2.2)

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

Re: [GENERAL] sequence... my nightmare :-(

On Sat, Sep 27, 2008 at 10:21 AM, Alain Roger <raf.news@gmail.com> wrote:
> if i double-quote it, postgre tells me that the column accounts_id_seq does
> not exist.

You almost got it. You need to doublequote to tell nextval with
capitalization correctly, then single quote that so the query planner
doesn't say "oh look! An identifier!

create sequence "Abc";
CREATE SEQUENCE
select nextval('Abc');
ERROR: relation "abc" does not exist
select nextval('"Abc"');
nextval
---------
1
(1 row)

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

[COMMITTERS] pgsql: Compare escaped chars case insensitively for ILIKE - per gripe

Log Message:
-----------
Compare escaped chars case insensitively for ILIKE - per gripe from TGL.

Modified Files:
--------------
pgsql/src/backend/utils/adt:
like_match.c (r1.22 -> r1.23)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/like_match.c?r1=1.22&r2=1.23)

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

[pgadmin-support] Re: [Fwd: Re: sudden program termination: no warning, error, or crash]

On Sep 26, 12:34 pm, a9006...@unet.univie.ac.at (Erwin Brandstetter)
wrote:
> Hi Kev!
>
> Please send this to the list, not to my private email account:
>
> pgadmin-supp...@postgresql.org
>
> Regards
> Erwin

Oh, no wonder...after a certain amount of time, there isn't actually a
"reply" option on Google Group threads anymore. Sorry again.

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