Hey,

Just wondering if there is currently any mechanism in the contrib makefile
hierarchy for installing header files into an appropriate directory.  I didn't
find anything.

I'm using PGSphere (spherical types/operators), and trying to help them out a
little here and there.  When I converted my application over to use their
type/operators, I found that although the shared library is installed fine,
there appears to be no method for installing the header files into the
production directory scheme.

Since the library is installed into the pgsql/lib directory, shouldn't the
header files required by server side development be installed into
pgsql/include? Maybe not by default, but with a 'install-all-headers' like
option?

Thanks,
Rob

-- 
 22:05:34 up 21 days, 14:47,  4 users,  load average: 2.01, 2.03, 2.00
Fri, 22 Aug 2003 22:17:17 -0600
Robert Creager <Robert_Creager@LogicalChaos.org>
Header files installed for contrib modules?
Robert Creager writes:

> Just wondering if there is currently any mechanism in the contrib makefile
> hierarchy for installing header files into an appropriate directory.

There isn't, because until now there was no need for it.  But there is no
reason that it couldn't be added.

-- 
Peter Eisentraut   peter_e@gmx.net


Sat, 23 Aug 2003 21:16:38 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Header files installed for contrib modules?
Dave Cramer writes:

> I'm working on identifying various errors in ecpg using sql state and
> one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
> file which isn't found. This is returned in a number of places. Is it
> possible to get a set of file specific error codes?

That error code if for undefined objects, not files that can't be found.
Can you identify the cases you are concerned about?

-- 
Peter Eisentraut   peter_e@gmx.net


Sat, 23 Aug 2003 21:42:06 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: ambiguous sql states
I'm working on identifying various errors in ecpg using sql state and
one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
file which isn't found. This is returned in a number of places. Is it
possible to get a set of file specific error codes?

Dave

-- 
Dave Cramer <dave@fastcrypt.com>
fastcrypt


23 Aug 2003 16:03:36 -0400
Dave Cramer <dave@fastcrypt.com>
ambiguous sql states
Robert Creager writes:

> So would one of you fine hackers be willing to add this feature?  If not, I'll
> have a go of it.

There isn't any contrib module that would use it, so why bother?

> Would this be best accomplished using a sub-directory which contains the header
> files to install, or a make variable containing the headers?

The latter.

-- 
Peter Eisentraut   peter_e@gmx.net


Sat, 23 Aug 2003 23:56:39 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Header files installed for contrib modules?
Specifically, if you try to open a file for copy, and it isn't there it
will return

int
errcode_for_file_access(void)
{

                case ENOENT:                    /* No such file or
directory */
                        edata->sqlerrcode = ERRCODE_UNDEFINED_OBJECT;
                        break;
                                                                                                                                                                            
Dave

On Sat, 2003-08-23 at 15:42, Peter Eisentraut wrote:
> Dave Cramer writes:
> 
> > I'm working on identifying various errors in ecpg using sql state and
> > one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
> > file which isn't found. This is returned in a number of places. Is it
> > possible to get a set of file specific error codes?
> 
> That error code if for undefined objects, not files that can't be found.
> Can you identify the cases you are concerned about?
-- 
Dave Cramer <dave@fastcrypt.com>
fastcrypt


23 Aug 2003 18:50:57 -0400
Dave Cramer <dave@fastcrypt.com>
Re: ambiguous sql states
On Sat, 23 Aug 2003 21:16:38 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net> said something like:

> Robert Creager writes:
> 
> > Just wondering if there is currently any mechanism in the contrib makefile
> > hierarchy for installing header files into an appropriate directory.
> 
> There isn't, because until now there was no need for it.  But there is no
> reason that it couldn't be added.
> 

So would one of you fine hackers be willing to add this feature?  If not, I'll
have a go of it.

Would this be best accomplished using a sub-directory which contains the header
files to install, or a make variable containing the headers?

Cheers,
Rob

-- 
 17:11:53 up 22 days,  9:53,  4 users,  load average: 2.34, 2.18, 2.05
Sat, 23 Aug 2003 17:16:12 -0600
Robert Creager <Robert_Creager@LogicalChaos.org>
Re: Header files installed for contrib modules?
Peter Eisentraut <peter_e@gmx.net> writes:
> Dave Cramer writes:
>> I'm working on identifying various errors in ecpg using sql state and
>> one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
>> file which isn't found. This is returned in a number of places. Is it
>> possible to get a set of file specific error codes?

> That error code if for undefined objects, not files that can't be found.

Dave's correct, that's what we're currently using.  I'm happy to change
it if someone can suggest an appropriate SQLSTATE (even a category...)
to use instead.

I would however like to know why ecpg cares.

			regards, tom lane

Sun, 24 Aug 2003 16:46:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ambiguous sql states 
Tom,

The reason it is of importance to me/ecpg is for informix compatibility.

informix returns a unique errorcode for the copy operation when the file
is not found. this isn't much of an argument from a postgres POV,
however I still find the sqlstate to be ambiguous. 


Dave

On Sun, 2003-08-24 at 16:46, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Dave Cramer writes:
> >> I'm working on identifying various errors in ecpg using sql state and
> >> one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a
> >> file which isn't found. This is returned in a number of places. Is it
> >> possible to get a set of file specific error codes?
> 
> > That error code if for undefined objects, not files that can't be found.
> 
> Dave's correct, that's what we're currently using.  I'm happy to change
> it if someone can suggest an appropriate SQLSTATE (even a category...)
> to use instead.
> 
> I would however like to know why ecpg cares.
> 
> 			regards, tom lane
> 
-- 
Dave Cramer <dave@fastcrypt.com>
fastcrypt


24 Aug 2003 17:14:37 -0400
Dave Cramer <dave@fastcrypt.com>
Re: ambiguous sql states
Tom Lane writes:

> Dave's correct, that's what we're currently using.  I'm happy to change
> it if someone can suggest an appropriate SQLSTATE (even a category...)
> to use instead.

I had a private chat with Dave about this.  It was my view that a missing
file that is read by a backend COPY is indistinguishable from, say, a
missing table or trigger, as far as recovery options by the client
application are concerned.

> I would however like to know why ecpg cares.

It doesn't.  This is related to an Informix porting project, which
apparently has a separate error code for its LOAD command.  Why exactly
that would affect our COPY isn't totally clear to me.

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 24 Aug 2003 23:24:50 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: ambiguous sql states 
Peter Eisentraut <peter_e@gmx.net> writes:
> I had a private chat with Dave about this.  It was my view that a missing
> file that is read by a backend COPY is indistinguishable from, say, a
> missing table or trigger, as far as recovery options by the client
> application are concerned.

Hm.  One problem in this area is that a file-not-found error could be a
user error (if the user-specified name in COPY or lo_import() or some
such is not found).  Or it could be a Postgres internal error (if a file
internal to the database can't be found).  I'm not sure it's real
practical to distinguish these cases in the code, unfortunately ---
unless people are excited enough about it to invent
errcode_for_user_file_access() as distinct from
errcode_for_file_access().  (Even if we wanted to do this, I'm unsure
how far up the changes might need to propagate.)

In either case, though, it is arguable that it's not appropriate to put
it under the "syntax error" SQLSTATE category.

			regards, tom lane

Sun, 24 Aug 2003 17:27:28 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ambiguous sql states 