You can get the database system identifier from the OS shell as part of the control data:
pg_controldata /Library/PostgreSQL/9.1/data
Here, '/Library/PostgreSQL/9.1/data' is my data directory on os x; replace it with your own data directory.
From there, you can isolate the database system identifier with grep:
pg_controldata /Library/PostgreSQL/9.1/data | grep "system identifier"
This is not the same as calling a function within a SELECT statement, but using the shell command above, one could easily write a function that returns the database system identifier as a string in a SQL query.
I hope this solves the problem.
On Thu, Dec 8, 2011 at 4:57 PM, Scott Mead
<scottm@openscg.com> wrote:
On Thu, Dec 8, 2011 at 4:27 PM, Bruce Momjian
<bruce@momjian.us> wrote:
Joshua D. Drake wrote:
>
> On 12/08/2011 12:57 PM, Bruce Momjian wrote:
> >
> > Chris Redekop wrote:
> >> Is there any way to get the database system identifier via a select
> >> statement? I have a primary/secondary async replication setup, and I'd
> >> like be able to verify from the client side that the provided primary and
> >> secondary connection strings do in fact refer to the same data set...
> >
> > Wow, that is a reasonable thing to want available via SQL, but I can't
> > see a way to get to it.
> >
> > The only method I can suggest is to write a server-side C function that
> > calls GetSystemIdentifier().
select inet_server_addr()?
--Scott
>
> This seems like something we should have in core, don't you think?
Yeah, kind of, except this is the first request we ever got for this.
The identifier is passed as part of streaming replication, so maybe it
will be needed more in the future.